AODV implementation for Ipv6

[ashvini vyavhare]

Hello,

According many  discussion on AODV implementation for Ipv6, I did all serialize, deserialize functions and ipv4 to ipv6 changes. It got built, but when I try to use it; it fails in assert - Icmpv6L4Protocol.cc line 1272. I think it is caused by net-device pointer that I am passing through callback UnicastForwardCallback. That one net-device parameter is the change from ipv4 callback code. But I am not sure. I am not clear about that net-device parameter for the unicast forward callback. Should it be input net device or output net device for a packet? Can anyone please help in this regard?

Thanks & Regards,
Ashvini

[Tommaso Pecorella]

Hi,

the callbacks need a pointer of the net device the packet was received from. I.e., the receiving NetDevice. As a side note, you can't have a pointer to the trsmitting NetDevice, it's on another node...

However, the assert you're telling is strange.

At line 1272 there's this function:

Ptr<NdiscCache> Icmpv6L4Protocol::CreateCache (Ptr<NetDevice> device, Ptr<Ipv6Interface> interface)

and no assert...

Double check please (and use the latest ns-3).

Cheers,

T.

[ashvini vyavhare]

Hi,

 

Thank for the clarification Tommaso.

And regarding latest ns-3, I am using ns-3.22 release. I found this one as latest.

Do I need to get any other version??

 

 

Regards,

Ashvini

[ashvini vyavhare]

 

The assert I mentioned in Icmpv6L4Protocol.cc file at line 1272, is in FindCache function.

 

 

Regards,

Ashvini

[Shashidhar B.L]

Hi Ashvini,

I am working on the same implementation. I am in the build process right now. Is it possible to share the code?? Also, have you designed test cases for checking the functionality??

Regards

Shashidhar B.L

[Tommaso Pecorella]

Hi,

the assert is hit when you try to find the ND cache for a given NetDevice. The problem is that a NetDevice could not have a ND cache. In this case, the function will fail.

I don't know where this code is used in AODV, but I'd check first if the NetDevice could have a cache at all. 

Right now I don't know where this function should be used. I.e., where is the point in the actual AODV for IPv4 is finding the NetDevice ARP cache. Perhaps you can avoid using FindCache at all. Remember that the ND cache is stored in the Ipv6Interface as well:

Ptr<NdiscCache> Ipv6Interface::GetNdiscCache ()

This function will (just) return zero if the cache is not there.

Cheers,

T.

On Tuesday, March 17, 2015 at 5:15:03 AM UTC+1, ashvini vyavhare wrote:

[ashvini vyavhare]

Hi,

No I haven't designed any test cases. Also I found that my approach in the implementation had flaws. So, working on it now.

Regards,
Ashvini

[Shashidhar B.L]

Hi,

I am working on finding solutions to few of my implementation problems. If I have any update, will keep you posted. Kindly do the same, it will be helpful to everyone. 

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/n1Hq7cKGCKI/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,

Did anyone find a solution to this problem? I dont think NetDevice can have an entry in the NdiscCache.

I did not understand how to avoid using FindCache. Could you please explain?

Regards

Shashidhar B.L

[Tommaso Pecorella]

As I said, I can't find where the AODV (the v4) code is using the ARP cache.

Without this information, I can't say if you're just trying to do something silly or if you have a real issue.

I said explicitly to tell me where and why you should check the NDISC cache in AODV.

Since you failed to provide this simple information, be my guest in keep searching for an answer by yourself.

T.

[Shashidhar B.L]

Hi,

The issue was in the RouteOutput section of routing protocol. During the router solicitation packet processing, the list routing asks routeoutput to find a route to the FF02::2 destination. If the RouteOutput is unable to find a route, then it calls for a loopbackroute, where the packet is withheld till a route is found. In the loopbackroute, it doesn't have a netdevice assigned which therefore cannot be found in the cache. But this is not suppose to happen, as RouterSolicitation shouldn't be looped back, and it was missing in my RouteOutput function. I fixed this. 

Thank you for your response.

Regards

Shashidhar B.L

--

[Tommaso Pecorella]

FF02::2 us handled by ListRouting right now (it's gonna change).

ListRouting MUST be always used with IPv6 routing up to ns-3.23. I hope that this limitation will be removed in 3.24.

T.

[Shashidhar B.L]

Hi,

I had another doubt, does Ipv6StaticRouting handle the FF02::2 packets?(based on the ripng logs, i see that the staticroutingprotocol gets highest priority for a FF02::2 packet)

 

In my application, I have installed AODV ipv6 on all the nodes (as you had suggested) and followed the ripng-simple-network topology, where there are 2 host nodes and 4 routers. When I try to use the listrouting on these 2 host nodes, and set a default route with each node and its neighboring router, it throws an error that i cant setdefaultroute. What am I missing?? Could you please let me know?

Regards

Shashidhar B.L

[Tommaso Pecorella]

Hi,

sorry, I get confused myself (and I should re-check the code before posting).

The problem with Link-local multicast (sending and receiving) is twofold.

Receiving: the function called is RouteInput. Link-local multicast must not be forwarded, so the only check is if it must be locally delivered.

Actually the check is... strange, almost a bug. Any protocol can happily do this check as well, it's "just" code duplication.

StaticRouting does NOT do this check, and ListRouting simply passes any multicast packet to the upper layers (ouch).

My future refactoring is meant to avoid this.

Sending: this is a no-brain problem. The function involved is RouteOutput and the only mandatory thing is to have a socket bound to an output interface.

If you don't bind the socket (at least in StaticRouting) an assert will be thrown. The reason is simple: you can't choose an appropriate interface.

To be honest we should do the same for any link-local address. And remove the assert if there's only one interface.

About the SetDefaultRoute, you need StaticRouting for this. Perhaps you didn't install it ?

Without the code, I can't be more precise, sorry.

Have fun,

T.

[Shashidhar B.L]

Hi,

That elaborate answer was indeed very helpful. Much appreciated Tommaso. 

About the last lines, I meant SetDefaultRouteInAllNodes and not SetDefaultRoute (my typo mistake). Does this require Ipv6StaticRoutinghelper to be installed on the node??

basically, its not letting me use ListRoutingHelper, AodvIpv6 and SetDefaultNodeInAllRoutes together on a host node which is connected to a Router. 

To clarify the setup, 

I have a src node (not a router), connected to a routerA

I have a dst node (not a router), connected to routerD

when configuring this interface, when i use SetDefaultNodeInAllRoutes(i), where i being interface index of router, it throws an error. does this have to do with static routing?

Code snippet:

  ipv6.SetBase (Ipv6Address ("2001:1::"), Ipv6Prefix (64));

  Ipv6InterfaceContainer iic1 = ipv6.Assign (ndc1);

  iic1.SetForwarding (1, true);

  iic1.SetDefaultRouteInAllNodes (1);    (error)

  ipv6.SetBase (Ipv6Address ("2001:2::"), Ipv6Prefix (64));

  Ipv6InterfaceContainer iic7 = ipv6.Assign (ndc7);

  iic7.SetForwarding (0, true);

  iic7.SetDefaultRouteInAllNodes (0);    (error)

/*****for reference, nodes assigned in same order to ndc via a nodecontainer*****/

 ndc1=src,a

 ndc7=d,dst

Regards

Shashidhar B.L

[Tommaso Pecorella]

Hi,

yes, SetDefaultRouteInAllNodes requires StaticRouting to be present in all the nodes [of the Ipv6InterfaceContainer].

As a side note, for AODV all the nodes are routers. there's no real difference between a router and a node.

Unless, of course, you are planning to modify AODV a lot, and let it handle submits instead of addresses.

Have fun,

T.