5.5.1 Routing Module

In general, every routing implementation in ns consists of three function blocks:

Notice that when implementing a new routing protocol, one does not necessarily implement all of these three blocks. For instance, when one implements a link state routing protocol, one simply implement a routing agent that exchanges information in the link state manner, and a route logic that does Dijkstra on the resulting topology database. It can then use the same classifiers as other unicast routing protocols.

Figure 5.3: Interaction among node, routing module, and routing. The dashed line shows the details of one routing module.

When a new routing protocol implementation includes more than one function blocks, especially when it contains its own classifier, it is desirable to have another object, which we call a routing module, that manages all these function blocks and to interface with node to organize its classifiers. Figure 5.3 shows functional relation among these objects. Notice that routing modules may have direct relationship with route computation blocks, i.e., route logic and/or routing agents. However, route computation MAY not install their routes directly through a routing module, because there may exists other modules that are interested in learning about the new routes. This is not a requirement, however, because it is possible that some route computation is specific to one particular routing module, for instance, label installation in the MPLS module.

A routing module contains three major functionalities:

  1. A routing module initializes its connection to a node through []register, and tears the connection down via []unregister. Usually, in []register a routing module (1) tells the node whether it interests in knowing route updates and transport agent attachments, and (2) creates its classifiers and install them in the node (details described in the next subsection). In []unregister a routing module does the exact opposite: it deletes its classifiers and removes its hooks on routing update in the node.
  2. If a routing module is interested in knowing routing updates, the node will inform the module via
    [dst, target]RtModule::add-route and [dst, nullagent]RtModule::delete-route.
  3. If a routing module is interested in learning about transport agent attachment and detachment in a node, the node will inform the module via
    [agent, port]RtModule::attach and [agent, nullagent]RtModule::detach.

There are two steps to write your own routing module:

  1. You need to declare the C++ part of your routing module (see ~ns/rtmodule.{cc,h}). For many modules this only means to declare a virtual method name() which returns a string descriptor of the module. However, you are free to implement as much functionality as you like in C++; if necessary you may later move functionality from OTcl into C++ for better performance.
  2. You need to look at the above interfaces implemented in the base routing module (see ~ns/tcl/lib/ns-rtmodule.tcl) and decide which one you'll inherit, which one you'll override, and put them in OTcl interfaces of your own module.
There are several derived routing module examples in ~ns/tcl/lib/ns-rtmodule.tcl, which may serve as templates for your modules.

Currently, there are six routing modules implemented in ns:

Table 5.2: Available routing modules
Module Name Functionality
RtModule/Base Interface to unicast routing protocols. Provide basic functionality to add/delete route and attach/detach agents.
RtModule/Mcast Interface to multicast routing protocols. Its only purpose is establishes multicast classifiers. All other multicast functionalities are implemented as instprocs of Node. This should be converted in the future.
RtModule/Hier Hierarchical routing. It's a wrapper for managing hierarchical classifiers and route installation. Can be combined with other routing protocols, e.g., ad hoc routing.
RtModule/Manual Manual routing.
RtModule/VC Uses virtual classifier instead of vanilla classifier.
RtModule/MPLS Implements MPLS functionality. This is the only existing module that is completely self-contained and does not pollute the Node namespace.

Tom Henderson 2011-11-05