Populating Custom Routing Table

[Ubaid ur Rahman]

Hello,

I want to populate routing tables on nodes in the network for my routing to work, now one solution is that I use static routes but I don't want to. Instead I want to create routing tables based on my own criteria and i.e. a router must know only its neighboring networks.

So far what I gathered from reading manual and going through source code, GlobalRouteManager is responsible for populating the static routes on each node, populates a link state database with LSAs gathered from the entire topology. Then, executes the OSPF shortest path first (SPF) computation on the database, and populates the routing tables on each node. The routing protocol extending Ipv4RoutingProtocol can use this information for running a query in order to forward or deliver the packet.

I don't need this behavior, I don't require LSA's from entire topology; instead I want only neighbors to share their link state, and based on that information I populate routing table. Now is there any API available in NS3 for this sort of functionality (which I didn't find -- probably need 2 more pairs of glasses). If not can you please guide me on the right direction as to how can I approach this. 

[Tommaso Pecorella]

Hi,

yes, you need a new pair of glasses. Or we need a better documentation. Or both :)

First the good part: you mostly did understand what GlobalRouting and StaticRouting do.

The bad part is that you misunderstood how the two are related. the answer is: they aren't related at all, GlobalRouting doesn't rely on StaticRouting. 

This is somewhat counterintuitive (at first): each protocol has its own routing table, and they update them independently. If there are two conflicting entries (it could happen), the resolution is done at a higher level. However, first things first... ListRouting.

In ns-3 the IP layer (v4 or v6) has a routing protocol. Just one, mind. However, that going protocol can be the ListRouting. In this case the ListRouting is responsible for asking the various routing protocols in its list (it's ListRouting) if they have an entry for the packet. The list is organized as a priority list, and the protocol with the highest priority wins. The next protocol is called only if the previous protocol doesn't know how to route a packet (i.e., it would have dropped the packet).

As a consequence, you usually install GlobalRouting *and* StaticRouting, with Static having an higher precedence over Global. In this way, you can inject "exceptions" in Static.

And now about the APIs you missed. You missed them because they're not there. The only APIs you must override are the ones in Ipv[4,6]RoutingProtocol. Basically RouteInput, RouteOutput and some other obvious ones. How you fill your routing table is completely left to your own design and functions.

For an example of possible designs, check AODV, DSR, OLSR, RIPng, etc. All are in the respective modules except for RiPng, that is so small that we placed it in the Internet module. All of the, of course, are dynamic and based only on 1-hop available informations (or data rebroadcasted from 1-hop neighbors).

Hope this helps,

T.

[Ubaid ur Rahman]

Hello,

Seeing how much you had to explain... Better documentation definitely! May I suggest adding some sub-domains to your primary domain i.e nsnam.org such as blogs, tutorials like some web frameworks provide. Any user who want to contribute may write some tutorial or a small blog post to explain what problem he/she faced and what was the solution. Blogs and tutorials are certainly more helpful.

[Tommaso Pecorella]

Hi,

it's a nice idea, well see if this fits with the documentation model.

There could be (indeed) a problem of missing links. The manual and tutorial are one thing, then there's the "standard" documentation main page (https://www.nsnam.org/documentation/, videos and presentations are there) and then there's the often-forgotten wiki... https://www.nsnam.org/wiki/Main_Page. Inside the wiki there's a long list of How-Tos, some of them very interesting.

Cheers,

T.

[Ubaid ur Rahman]

Hello,

Current documentation is somehow limited, and is ideal for someone who has a bit of experience with NS3, video tutorials... man they are boring, and the wiki How-Tos are limited. The true potential of NS3 I think is not covered in current documentation. Just carry out a survey, ask user's how difficult it was to learn NS3 at the beginning, may be you'll get some interesting results.

As for me... I would be happy to help in making the website more attractive, write some articles and any other side where I can.

[Tommaso Pecorella]

Hi,

well, you know, the docs are always the hard part. This is because it's inherently hard to write good docs: the developer find it boring, and he/she gives for granted a lot of things which are important for the user... and viceversa !

I'm a dev (and a teacher), and I find it very difficult to write good docs because I never know if something is useful or not. E.g., shall I explain in detail what's the on-path model for IPv6 or not ? Well, for the normal user it's probably not important, while for a routing dev is dramatically important.

Anyway, any constructive criticism is welcome. If you want to contribute to the docs, poke Tom (Henderson).

Cheers,

T.

[Ubaid ur Rahman]

Hello,

Will certainly do! :)