dynamic routing with different cost function

68 views
Skip to first unread message

Deb

unread,
Apr 4, 2017, 9:51:30 AM4/4/17
to ns-3-users
Hi,

I am trying to simulate a very large network consisting of 50k nodes and a million links. The link capacities vary with time. Hence I need to incorporate a dynamic link state routing (OSPF) with a different cost function (based on bandwidth) so that routes can be re-computed when the available bandwidth changes. What can be the simplest way to do this in ns3? 

I know the obvious answer which is to use quagga. But unfortunately the quagga website does not have enough documentation for handling different cost functions. So, hereby I ask the ns3 experts for better and wiser insights. Obviously I want to avoid manual configurations! I promise to pay back by documenting and publishing my code online once I am done with the simulations.

Thanks!

Tommaso Pecorella

unread,
Apr 10, 2017, 6:09:10 PM4/10/17
to ns-3-users
Hi,

GlobalRouting mimics an OSPF routing algorithm, and you can change the link metric using the Ipv4Interface::SetMetric function (and then forcing a new routing computation).
I have no idea how this can scale tho... your numbers are pretty huge.

NixRouting is way faster, but it doesn't consider the link metric as far as I know. It should be possible to extend it tho.

Cheers,

T.

Deni Toruan

unread,
Oct 20, 2017, 7:52:57 AM10/20/17
to ns-3-users

Dear Tommaso,

I am sorry to address a new question in this thread. I am interesting with your comment: "and then forcing a new routing computation". Is it mean we can simulate the dynamic routing feature of OSPF by this method? thank you.

regards,

deni toruan

pdbarnes

unread,
Oct 20, 2017, 11:49:32 AM10/20/17
to ns-3-users
IIRC global (God) and Nix-vector use the same Djikstra to find shortest paths, so if you can set the metric for one it should be possible to do the same for the other.

To recompute routes it's something like FlushXCache, search the Doxygen.

Finally, you'll almost certainly be better off with NixVector than God routing. God routing in your problem will compute (50k)^2 /2 = 1.25B routes. You probably have many many fewer routes in use, so NixVector will be faster.

Peter

Reply all
Reply to author
Forward
0 new messages