Discrepancy btw ns-3 implementation and RFC3561 - RREP Fields in AODV

[cha]

TLDR: Why Originator IP address field in RREP message corresponds to RREP originator, which contradicts with AODV documentation? 

Long version: 

Can someone give an insight about the difference between RREP fields in ns-3 and the RFC3561 (AODV documentation)? 

Specifically, I am asking the interpretation of two IP address fields in RREP message. Those two fields are copied from RFC3561:

1. Destination IP Address
                       The IP address of the destination for which a route is supplied.
2.  Originator IP Address
                       The IP address of the node which originated the RREQ for which the route is supplied.

My understanding of these fields are as follows:

Say:

• Node A initiates RREQ to Node E

• E generates RREP and sends it back to A

Then:

• RREP Packet Payload:

  • Destination IP Address = E

  • Originator IP Address = A

However, in the ns-3 implementation, it looks like these two fields are swapped, i.e., originator (destination) corresponds to RREP originator (destination), but NOT RREQ originator (destination). 

Lines 1639 and 1723 of aodv-routing-protocol.cc

NS_LOG_LOGIC("RREP destination " << dst << " RREP origin " << rrepHeader.GetOrigin());

RoutingTableEntry toOrigin;

if (!m_routingTable.LookupRoute(rrepHeader.GetOrigin(), toOrigin) ||

toOrigin.GetFlag() == IN_SEARCH)

{

return; // Impossible! drop.

}

This could not be a mistake (obvious that it's done intentionally) so I am trying to understand the reason of this discrepancy between the official documentation and ns-3 implementation.

[Tommaso Pecorella]

Hi Cha,

thanks for reporting this, you might have found a bug. The problem is that usually this kind of problems comes in pair - you do a mistake in the message creation AND in its reception. Two wrongs make one right, and your code looks right (but it isn't).

The code works, and you find the dsicrepancy only by looking carefully at the wireshark traces, or when you try to do an interoperability test.

Please open an issue in our tracker, possibly highlighting it with a wireshark capture. Of course a bugfix would be super-helpful.

[Tom Henderson]

I stored this in an issue so that possibly someone will work on it further:

https://gitlab.com/nsnam/ns-3-dev/-/issues/1257

A patch to fix would be welcome.

- Tom

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ns-3-users/17616dca-9f21-48a8-a96d-85e0f2d6913fn%40googlegroups.com.

[cha]

Hi Tommaso, Tom,

Thank you for your inputs. It is a privilege to receive replies from the top two people in ns-3. I really appreciate your time!

Regarding this issue, I believe I’ve figured it out (sorry I should have followed-up earlier). The main confusion comes from the line (1639 of aodv-routing-protocol.cc in ns-3.45):

NS_LOG_LOGIC("RREP destination " << dst << " RREP origin " << rrepHeader.GetOrigin());

where, the variable dst is defined in the previous line as:

Ipv4Address dst = rrepHeader.GetDst();

According to RFC 3561, this(dst) should correspond to the RREQ destination. Likewise, rrepHeader.GetOrigin() should be the RREQ originator, not the “RREP origin.” The good news is that’s indeed the case in implementation:

• rrepHeader.GetOrigin() returns the RREQ originator.

• rrepHeader.GetDst() returns the RREQ destination.

I haven’t yet used the Wireshark approach Tommaso suggested, but I ran several tests in debug mode and verified this behavior from the RREP headers.

What confuses me is the logging terminology: the code labels them as “RREP destination” and “RREP origin.” Perhaps the intent was to emphasize that in AODV the RREP destination equals the RREQ destination, but the wording feels misleading.

In short, swapping the labels (or making them more explicit) could make the logging clearer and help future users avoid this confusion.
If you’d like, I can provide a similar input to the issue that Tom opened yesterday.  
Thanks!

[Tommaso Pecorella]

Hi Cha,

yes, perhaps it's the logging that is bad. Please add this comment to the issue, so we can fix it in the proper way.

Tnx, T.

[Tommaso Pecorella]

Hi Cha,

sorry for the super-long delay. I finally checked everything and the good news is that - indeed - it's just a matter of logging.

The problem is that the AODV RFC clearly indicates the field of the header, and the "destination" is exactly the one of the RREQ. As confusing as it might seems, the RFC is clear, and swapping the fields in the log would be even more confusing if then one looks at the packets with Wireshark.

The best option (in my opinion) is to refer to the in the log as "route destination" and "route origin", which should partially clarify them.

Opinions ?

[A C]

Hi Cha,

Are you using any FPGA board or other types of boards here?

Regards,

Ashmita

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ns-3-users/8c2df9df-765c-4353-ade9-a30b8e9bedean%40googlegroups.com.