Distributed Archticture
The Toolkit architecture is designed to run on the new generation of
multi-processor workstations. MRT explores many of the advanced
operating system features on these machines, such as the use of multiple
threads, shared memory and distributed processing. The Toolkit supports
both SunOS and Solaris, though the code runs much faster on Solaris.
The design and architecture of MRT grew out of our experience implementing the IDRP protocol in GateD, a routing daemon developed at Cornell University. Until the release of MRT, GateD was the only freely available platform for researchers to experiment with new routing protocols and policies. Designed as a production quality routing daemon, GateD offers a highly optimized code base. Although optimized code and binaries are desirable for the fast processing of routing updates, optimization makes maintaining and debugging code, as well as adding new features, considerably more difficult. The MRT architecture emphasizes the software engineering goals of code readability and maintainability over run-time speed and memory efficiency. MRT also provides a well-documented and clearly defined application programming interface.
As the Internet and associated inter-domain routing protocols and policies continue to grow in both size and complexity, Internet researchers require increasingly sophisticated tools to analyze these new routing environments. The hierarchical network model of the NSFNET is rapidly being replaced by a mesh topology of routing domains with many more peer sessions and varied routing policies. MRT provides a collection of stand-alone tools that may be used separately, or combined together to analyze such routing problems as route flapping, the effects of route aggregation, and the effect of changes in routing policy on network topology.
The rapid advances in routing technology have also created a need for a platform on which researchers can quickly prototype new routing protocols and routing engines. We expect MRT will provide a code base for the development of such new features as multiple views, quality of service, multicast, source routing, and IPV6.
Overview of Distributed MRT architecture.
Our experience with IDRP taught us that developing routing protocols is a relatively easy task as compared with debugging protocols. For every hour spent implementing a new feature, engineers later spend three hours debuging the new source code. The Toolkit provides tools that greatly simplify the process of analyzing and debugging routing protocols. Amongst other features, the Toolkit allows for the recreation of time-based routing events, the editing of routing protocol packets, and the complete logging of all packets in a peering session.
Advanced Features
MRT takes full advantage of new features in computer operating systems
and architectures, including multiple threads and shared memory.
Because GateD was designed to operate over the widest possible range of
computer architectures and operating systems, the GateD designers were
unable to take advantage of features only offered on specific
platforms. Since MRT is designed to work only on Sun workstations, the
toolkit does not suffer from these limitations. We expect the use of
multiple threads and other advanced features will give MRT routing
daemons significantly better performance over traditional routing
daemons when run on multi-processor machines. These advanced features will also
help minimize single points of failure in MRT daemons. On several
occasions, a minor memory error in one GateD protocol running on the
NSFNet backbone caused the daemon and all of its related routing
sessions to die. MRT separates the functionality of speaking routing
protocols and maintaining routing tables onto seperate lightweight
processes to minimize these single points of failure.
Streamlined Syntax
The Toolkit is also designed to simplify and facilitate everyday
routing tasks such as establishing a new peering session, and writing
new routing policies. Wherever possible, MRT tools allow users to avoid
creating complex configuration files and use simple command line
arguments. MRT understands RIPE-181 syntax directly and alleviates the
need for users to translate their routing policy database information
into special configuration languages.
Goals and Future Plans
The following two charts summarize some of the explicit goals and
non-goals that motivated the development of MRT:
In the future, we hope to use MRT to continue exploring the use of multiple threads in routing daemons. Although many researchers have studied the problem of parallelizing the flow of information through protocol stacks (See ....), little work has been done on using mulitiple threads in routing daemons. We also hope to continue research on the dynamics of route flapping and the development of algorithms to minimize their effects. Given enough time and funding, we would also like to use MRT as a base to implement IPV6 routing, quality of service routingin, and SDRIP, amongst other features.
See the MRT User's Guide for information about the Unix programs distributed with MRT. The Programmer's Guide provides more information about the C-libraries.