Overview: Development and Design

  • Introduction
  • Advanced Features
  • Streamlined Syntax
  • Goals and Future Plans

  • Introduction

    The Multi-threaded Routing Toolkit (MRT) provides a powerful collection of tools for developing and debugging inter-domain routing protocols and policies. The Toolkit consists of Unix programs and C-library routines that separate routing into its key component pieces of routing protocol, routing engine, and routing policy services. These programs and routines either may be used separately to investigate specific elements of routing, such as editing routing update packets, or may be combined together to form a fully functional routing implementation such as BGP4 or a Route Server.

    MRT can be used for:

    MRT also provides:

    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.



    Return to Merit home page


    Maintainer: www@www.merit.edu; Last Updated: 24 August 1995
    Copyright 1995, Merit Network, Inc.