next up previous contents index
Next: Index Up: 6. ns-3 routing Previous: 6.4 Support for multiple   Contents   Index


6.5 Roadmap and Future work

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:

Linux is probably the right implementation model for this, since BSD has mixed ARP and IP routing, unfortunately, and doesn't support multiple forwarding tables.

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

Global multicast routing 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.

In the future, work on bringing XORP or quagga routing to ns-3, but it will take several months to port and enable.

There are presently no roadmap plans for IPv6.


next up previous contents index
Next: Index Up: 6. ns-3 routing Previous: 6.4 Support for multiple   Contents   Index
Tom Henderson 2007-08-15