AODV Ipv6: Neighbour discovery and impact of "Notify" objects

[Shashidhar B.L]

Hi,

I am currently working on AODV ipv6 implementation. At the moment am testing it by creating network simulations and I had a few questions to ask.

1. Is the neighbour discovery taken care by the existing implementations in NS3 or is the routing protocol responsible for it at some point?

2. Based on my initial understanding, three objects"NotifyAddAddress", "NotifyInterfaceUp" and "NotifyInterfaceDown" are associated with neighbour discovery. If am wrong, please correct me. Also, could anyone explain to me, the significance of these objects (I have already read the documentation, a little more detail explanation would be really helpful).

3. I have used the same network topology as specified in the example 'ripng-simple-network.cc' for my aodv testing and I have noticed that the source and router A are able exchange ICMPv6 messages but the same does not occur between destination node and router D. Note: source and destination nodes are just hosts and don't have routing protocol installed on them. For the rest of the interfaces between Routers A,B,C and D, there are only four Neighbour Discovery messages exchanged, they are unable to go further than that. Could someone please explain the possible reasons for this? It would be really helpful. 

For the reference, the topology used is this: 

The idea is to use Ping6 application between SRC and DST node. 

 SRC

     |<=== source network

     A-----B

      \   / \   all networks have cost 1, except

       \ /  |   for the direct link from C to D, which

        C  /   has cost 10. SRC and DST are hose

        | /     A,B,C and D are configured as routers  

        |/

        D

        |<=== target network

       DST

I have attached three .pcap files. 

File ending with:

1. srcnode-0 is for the link between SRC and Router A.

2. dstnode-0 is for the link between DST and Router D.

3. RouterA-1 is for the link between Router A and Router B.

I have also checked out this link https://www.nsnam.org/wiki/HOWTO_use_IP_interface_indexes to ensure that my interface indexes used are correct. 

I have used the logs to trace the functioning of whole network and noticed that the nodes are joining the multicast groups via the solicited node multicast address, the nodes are also receiving the packets sent using just MAC addresses, but are unable to process them.

I found out that the RecvAodv is never called, which means the packet is not being processed (because the log says the packets are sent). Could this be a problem with the listen sockets? (I did check this, seemed right, but not 100% confident) If it is so, then could you please suggest a way to check this? If not, then what could be the source of this problem?

The simulation runs successfully with no errors, just that it does not perform the required functionality. Also, logs say route not found to FF02::1 (All nodes multicast address). should the nodes not just listen to, at this address, why is a route required? 

Some questions might be really trivial, but I ask only when am really not able to find a solution. 

Any suggestions would be of great help and I would really appreciate that. 

Thank you for your patience and time.

Regards

Shashidhar B.L

[Tommaso Pecorella]

Hi,

On Wednesday, May 6, 2015 at 9:36:38 AM UTC+2, Shashidhar B.L wrote:

Hi,

I am currently working on AODV ipv6 implementation. At the moment am testing it by creating network simulations and I had a few questions to ask.

good to know. When you've done, I'll be happy to review it.

1. Is the neighbour discovery taken care by the existing implementations in NS3 or is the routing protocol responsible for it at some point?

It depends on what you mean. NDP (ICMPv6 ND/NA) is done by the IPv6 layer. However this isn't really a neighbor discovery in the true sense of the term. AODV can have its own ways.

 

2. Based on my initial understanding, three objects"NotifyAddAddress", "NotifyInterfaceUp" and "NotifyInterfaceDown" are associated with neighbour discovery. If am wrong, please correct me. Also, could anyone explain to me, the significance of these objects (I have already read the documentation, a little more detail explanation would be really helpful).

there's a 4th: NotifyRemoveAddress.

No, they're not for neighbor discovery. They are used to signal if an interface is added / removed or if an address is added / removed. Interface and address of the *local* node.

 

3. I have used the same network topology as specified in the example 'ripng-simple-network.cc' for my aodv testing and I have noticed that the source and router A are able exchange ICMPv6 messages but the same does not occur between destination node and router D. Note: source and destination nodes are just hosts and don't have routing protocol installed on them. For the rest of the interfaces between Routers A,B,C and D, there are only four Neighbour Discovery messages exchanged, they are unable to go further than that. Could someone please explain the possible reasons for this? It would be really helpful. 

No idea. Without the code I can't say.

Mind that in AODV all the nodes must have it installed. Perhaps it's this the reason ?

For the reference, the topology used is this: 

The idea is to use Ping6 application between SRC and DST node. 

 SRC

     |<=== source network

     A-----B

      \   / \   all networks have cost 1, except

       \ /  |   for the direct link from C to D, which

        C  /   has cost 10. SRC and DST are hose

        | /     A,B,C and D are configured as routers  

        |/

        D

        |<=== target network

       DST

I have attached three .pcap files. 

File ending with:

1. srcnode-0 is for the link between SRC and Router A.

2. dstnode-0 is for the link between DST and Router D.

3. RouterA-1 is for the link between Router A and Router B.

I have also checked out this link https://www.nsnam.org/wiki/HOWTO_use_IP_interface_indexes to ensure that my interface indexes used are correct. 

I have used the logs to trace the functioning of whole network and noticed that the nodes are joining the multicast groups via the solicited node multicast address, the nodes are also receiving the packets sent using just MAC addresses, but are unable to process them.

I found out that the RecvAodv is never called, which means the packet is not being processed (because the log says the packets are sent). Could this be a problem with the listen sockets? (I did check this, seemed right, but not 100% confident) If it is so, then could you please suggest a way to check this? If not, then what could be the source of this problem?

Not really. The AODV packets aren't in the caps, so probably they're not even sent. Double check this.

 

The simulation runs successfully with no errors, just that it does not perform the required functionality. Also, logs say route not found to FF02::1 (All nodes multicast address). should the nodes not just listen to, at this address, why is a route required? 

This probably is the problem. You need to have ListRouting in the nodes (this is not obvious) as it's the one handling the mandatory multicast addresses.

I have a routing refactoring in progress, but it's not yet ready for prime time.

Some questions might be really trivial, but I ask only when am really not able to find a solution. 

Any suggestions would be of great help and I would really appreciate that. 

Thank you for your patience and time.

No, the questions weren't trivial.

Cheers,

T. 

[Shashidhar B.L]

Hi,

Thank you for your response. I was hoping if you could see the attached script and tell me if the application is designed correctly, if the address assignments are appropriate in comparison to the Ripng-simple-network.cc. If it its so, then I would be eliminating the option that my application is wrong and can focus on the problems in the aodv ipv6 part. 

Could you please do this for me?

Regards

Shashidhar B.L

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/0Q66XmnYWcE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Shashidhar B.L]

Hi,

I had one more comment, I think the 'NotifyInterfaceUp' is indirectly responsible in the neighbor discovery process. Based on my understanding, two nodes in a link send the NeighborSolicitation (NS) packets across the interface. In the functionality of 'NotifyInterfaceUp', it is seen that sockets are created and entries to the routing table are made. 

I have few questions at this point:

1.Why does the notification involve adding entries to routing table, because basically what it is doing is adding its own address and interface to its own routing table.

2.This is silly question, I would rather embarrass myself asking this, than killing myself with this mind boggling question. For the same interface, should I create two sockets for the two addresses associated with the interface for ipv6 (Link Local and Global scope addresses). i.e two each for, listening, subnetbroadcast, local broadcast. 

3. How can I make sure that the socket is actually working? There is assert function to tell me if socket is not created, which am sure is created but may not be working.

On the whole, in my case, I have a strong feeling that this 'NotifyInterfaceUp' which am writing for aodv ipv6, isn't working as per requirement, mainly due to the sockets. 

For the reference I attach a small .cc file which has the 'NotifyInterfaceUp'. Could you please point at my mistakes? (I know its not your responsibility to review this, but I make a humble request)

Thanks in advance

Regards

Shashidhar B.L