Routing (including static routing) is a bit more complex than what is found in ns-2, which relies on a simple shortest path computation based on node ID or generic hierarchical addresses. Here, we want to account for the fact that our network may be composed of variably subnetted IP links, and we should offer some alternatives for defining link costs.
There are several components that need to be defined:
For static routing, we propose a RouteManager object, which is a singleton object responsible for populating per-node forwarding tables. When a user calls ``PopulateRoutingTables ()'', the RouteManager will walk the topology and build a network map representation of the network, will run a shortest path computation, and will then access the routing API of each node and populate the forwarding tables. Users may enter per-node static routes, in the usual way, that override the values placed in the table by the RouteManager. The RouteManager must deal with point-to-point and shared links, must correctly deal with IP subnetting (and perhaps use different approaches for different address families), and must allow for different cost metric assignments, such as ``every link is a single hop'' or ``link metrics are a function of the inverse of the bandwidth of the link''.
For dynamic routing, we propose to port XORP or quagga rather than rewrite routing protocols for ns-3. There is some experience with this in previous simulators; most notably, GTNetS has supported ports of quagga BSD and OSPFv3.
The routing API of a node should be a queriable interface with some implementation independence. Ideally, we ought to be able to use the same interface for both Linux and idealized stacks, and for manual routing configs as well as dynamic routing protocols such as XORP that use routing sockets directly.
The node forwarding table is instantiated by some object in the node; either an IPv4 or IPv6-layer object, or something like a ported Linux stack. It should have the following properties:
Users should be able to trace (either debug print, or redirect to a trace file) the routing table in a format such as used in an Unix implementation:
# netstat -nr (or # route -n) Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 127.0.0.1 * 255.255.255.255 UH 0 0 0 lo 172.16.1.0 * 255.255.255.0 U 0 0 0 eth0 172.16.2.0 172.16.1.1 255.255.255.0 UG 0 0 0 eth0 # ip route show 192.168.99.0/24 dev eth0 scope link 127.0.0.0/8 dev lo scope link default via 192.168.99.254 dev eth0
Static multicast should be implemented as well. This would ignore group membership and ensure that a copy of every sourced multicast datagram would be delivered to each node. This might be implemented as an RPF mechanism that functioned on-demand by querying the forwarding table, and perhaps optimized by a small multicast forwarding cache. It is a bit trickier to implement over wireless links where the input interface is the same as the output interface; other aspects of the packet must be considered and the forwarding logic slightly changed to allow for forwarding out the same interface.