In general, every routing implementation in ns consists of three
function blocks:
- Routing agent exchanges routing packet with neighbors,
- Route logic uses the information gathered by routing
agents (or the global topology database in the case of static
routing) to perform the actual route computation,
- Classifiers sit inside a Node. They use the computed
routing table to perform packet forwarding.
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:
- 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.
- 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.
- 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:
- 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.
- 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
2014-12-17