"In anything at all, perfection is finally attained
not when there is no longer anything to add, but
when there is no longer anything to take away..."
-- Antoine de Saint Exupery, "Wind, Sand and Stars"
(quoted in "Multics: The First Seven Years",
F. J. Corbato, J. H. Saltzer)
"One ring to rule them all, one ring to find them, one ring to bring them
all, and in the darkness bind them."
-- J. R. R. Tolkien, "Lord of the Rings"
NIMROD: It Might Run One Day.
"Nimrod is a scalable routing architecture designed to support a dynamic
internetwork of arbitrary size, to provide service-specific routing in the
presence of multiple constraints, and to admit incremental deployment
throughout an internetwork. The key features of Nimrod include
representation of internetwork connectivity and services in the form of maps
at multiple levels of abstraction; source- and destination-controlled route
generation and selection based on maps and traffic service requirements; and
source- and destination-controlled message forwarding according to the
routes selected." [Steenstrup94]
A fair amount of documentation for the
Nimrod Routing Architecture
never made it into
form. They are collected here, along with a list of the Nimrod RFC's.
If you're just starting, and trying to learn something about Nimrod, and
you're looking for one single document to read, at the moment the best thing
to start with is the Nimrod
which IMHO offers up the all important fundamental ideas, in the right order.
It is short on detail in many areas, so if you want to know more, good places
to go after that are the
Nimrod Routing Architecture
document, and the
Perspective on Nimrod Functionality.
Since many of the documents here are in rough draft form, please do not
reproduce anything here without the explicit permission of the author of the
BBN also used to maintain a
of Nimrod documentation, Nimrod source code, IETF WG minutes, IETF WG
presentations, and other material. Caveat haquur: there is much duplication
of material between here and there, and almost all significant document
material is available here.
Many people find
by Charlie Lynn particularly amusing, given the A. de Saint Exupery quote
(found above) used as a motto for Nimrod. (Available
as the original PostScript file.)
These are available from your nearest RFC server, but the listing here includes
a link to a copy at the main RFC server at USC-ISI.
1753 IPng Technical Requirements Of the Nimrod Routing and Addressing
Architecture; Noel Chiappa; December 1994. (Format: TXT=46586 bytes)
1992 The Nimrod Routing Architecture; Isidro Castineyra, Noel Chiappa,
Martha Steenstrup; August 1996. (Format: TXT=59848 bytes) (Status:
2102 Multicast Support for Nimrod: Requirements and Solution
Approaches; Ram Ramanathan; February 1997. (Format: TXT=50963 bytes)
2103 Mobility Support for Nimrod: Challenges and Solution Approaches;
Ram Ramanathan; February 1997. (Format: TXT=41352 bytes) (Status:
A New IP Routing and Addressing Architecture, July 1991
This is the document that started it all; the document that introduced the
basic Nimrod routing architecture.
This document presents one possible new IP routing and adressing
architecture. By routing and addressing it is meant that part of the overall
IP architecture which is responsible for identifying computing nodes,
where they are in the Internet, and how to get traffic from one to another. It
represents one person's view of a good overall system answer to this question,
and is not to be taken as anything more than that.
The Nimrod Routing Architecture, January 1995
This is a slightly earlier revision of the document than the
above (RFC-1992), and it is thus slightly out-of-date in some minor details,
but makes up for it by containing much useful material (particularly on
datagram mode) that was deleted from the architecture document (apparently in
a misguided attempt to make it shorter).
We present a scalable internetwork routing architecture, called Nimrod. The
Nimrod architecture is designed to accommodate a dynamic internetwork of
arbitrary size with heterogeneous service requirements and restrictions and
to admit incremental deployment throughout an internetwork. The key to
Nimrod's scalability is its ability to represent and manipulate
routing-related information at multiple levels of abstraction.
A Perspective on Nimrod Functionality, June 1994
This version of this document is slightly outdated (in that it speaks of the
Nimrod map containing arcs with attributes), but is otherwise useful. A
slightly later version of this document (May 1995) is available (in
PostScript form only)
We describe the Nimrod routing functionality, expressed in terms of the
relationships among a set of distributed databases of routing information
together with the procedures for constructing, accessing, and acting upon
Nimrod Functionality and Protocol Specifications,
This document contains a description of Nimrod functionality and a
specification of the protocols constituting Nimrod. In particular, the
operations pertinent to the map, locator, adjacency, route, and forwarding
databases are described, and the Reliable Transaction, Update,
Query-Response, Path Management, and Discovery protocols are specified.
A slightly earlier version of this document (undated, but circa May 1995),
including diagrams of such things "Adjacency Formation", is available (in
PostScript form only)
The Nimrod Routing Database, January 1995
This document presents a high level description of Nimrod's Routing
Nimrod Deployment Plan, January 1995
We describe how the Nimrod routing system can be deployed incrementally
into an internetwork, and in particular into the Internet. We discuss the
initial implementation required to obtain Nimrod functionality in some
places within an internetwork, and we also discuss the migration path to the
Endpoint Identifier Destination Option, May 1996
This document describes a Destination Option that is used to
convey topologically independent endpoint identification
information between source and destination endpoints in either IPv4
or IPv6 packets. ... The Nimrod Routing System will make use of
this option to convey Nimrod EIDs.
DNS Resource Records for Nimrod, October 1995
This document describes two additional RR types for the Domain Name
System required to implement the Nimrod Routing Architecture.
These RRs record the Nimrod Locator and an Endpoint Identifier (EID)
associated with a given Domain Name.
"We are releasing preliminary versions of the Nimrod protocol, procedure, and
database specifications as separate memos. ... This is .. a series of
articles that we expect, after revisions, to comprise the Nimrod Protcol
Specification document. Other members of the working group will cover the
following in other articles:
Eventually, all of this information will be integrated into a single Nimrod
specification document, but we figured that it would be easier for readers to
digest the memos separately rather than as one large document."
- Path Setup and Teardown Protocol
- Nimrod Database Contents organization
- Agent and Neighbor discovery protocols
- Reliable Transport Protocol
Nimrod Packet Forwarding and Path Management,
This (drafty) memo describes the Nimrod packet forwarding procedures
and path management protocol. The design is based on the one
described in the Nimrod functionality document ... We assume that the
reader is familiar with the terminology defined in the Nimrod architecture and
Hierarchical Update and Hierarchical Query-Response
Protocols for Nimrod, January 1995
This article describes the Hierarchical Update Protocol (henceforth referred
to simply as the Update Protocol) and the Hierarchical Query-Response
Protocol (henceforth referred to simply as the Q-R Protocol) for Nimrod.
Emphasis is on protocol engines and packet contents and not packet formats.
Additionally, we also briefly discuss the functionality of Map Construction
and Association Maintenance and their realization using the Update and Q-R
Nimrod Software Architecture, March 1995
In a Nimrod internet, Nimrod software will be run on both general
purpose computing platforms such as PCs and workstations as well as on
special purpose platforms such as routers and servers, from a variety
of vendors. However, not all platforms will need to support the full
range of functions described in the Nimrod Architecture and
Functionality documents. The software architecture must make it
straight forward for the vendors to move Nimrod code to their often
proprietary environments, possibly by porting code from a reference
implementation or by developing code directly from the Nimrod
Functional Specification. Thus the usual architectural goals of a
clean, modular design with clear inter-module interfaces becomes even
Nimrod functionality may be categorized into a collection of
databases, agents that both maintain and provide requested information
from those databases, and various support modules that provide the
communications and other services the agents need to perform their
tasks. Low level packet forwarding and discovery mechanisms are also
required. This document uses the paradigms of layering,
client-server, message passing, and events. Implementors may cast the
software architecture described here to other paradigms that may be
more suitable to their target platform(s).
Here are some slide sets which contain useful material.
A New Routing and Addressing Architecture for the Internet,
This presentation is also available in its original (slide) form:
Source (Tex): Part 1 2
3 4 5
PostScript (compressed): Part 1 2
3 4 5
This presentation includes sections on: Nimrod Design Goals And
Principles (something which is not covered well in any other document;
this section also includes a more detailed list of Technical Goals For
Nimrod); a Nimrod Architecture Overview (which looks at the two
basic underlying technical principles of Nimrod, and examines the
implications of that choice); and an Overview Of Nimrod Mechanisms
(which includes more detail on some, but not all, of the mechanisms and
capabilities of Nimrod).
This presentation also includes brief introductions to the topics of
Routing and Addressing Architectures (including discussion of the
various main classes of routing architectures, and the inherent problems of
routing in very large networks), and Architectural Fundamentals
(including discussion of names and objects).
Here are some rough introductory notes on various subjects.
Paperman for Nimrod, November 1993
This is an attempt to come up with the most basic---read primitive---version
of Nimrod I can think of. I wanted to have something we can criticize and use
as initial point of reference. I am explicitly not claiming that the design
decisions taken here would be part of any instantiation of Nimrod. That is,
this is not supposed to be a minimal design, only a simple one.
Representation, Configuration, and Route Information
Distribution, December 1993
In this write-up, I have put down my thoughts on representation,
configuration and route information distribution. Representation is discussed
in section 1, mainly as a basis for discussing section 2 on configuration and
route information distribution. Each section has a "theme" that summarizes
ideas of the section.
These are some chapters from a book which are relevant to Nimrod. The first
advances a new view of state and state management in the network. The second
gives a brief description of Nimrod, and talks about what data it would like
to see in an internetwork packet header.
Evolutionary Possibilities for the Internetwork Layer, July 1995
A project called Nimrod, which aims to produce a next-generation
routing architecture for the Internet, has produced, as part of its work, a
somewhat different perspective on the potential future evolutionary path of
the internetwork layer. This perspective is based on an established school of
thought about how to design large-scale systems. This section both explains
that thinking to some degree, and uses it to describe what the future
evolution of the internetwork layer might look like.
The Internetwork Layer and the Nimrod Routing Architecture, July 1995
Nimrod is a project which aims, in part, to produce a next-generation routing
architecture for the Internet; but also, more generally, to try and produce a
basic design for routing in a single global-scale communication substrate, a
design which will prove sufficiently flexible and powerful to serve into a
future as yet unforseeable.
Nimrod does this through the conjunction of two powerful basic mechanisms:
The actual operation is fairly simple, in principle. Maps of the network's
actual connectivity (maps which will usually include high-level abstractions
for large parts of that connectivity, in the same way road maps of an area
may not show all the roads, just the 'important' ones) are made available to
all the entities which need to select paths. Those entities use these maps to
compute paths, and those paths are passed to the actual switches, along with
the data, as directions on how to forward the data.
- Distribution of maps, as opposed to distribution of routing tables; and
- Selection of routes by clients of the network, not by the switches in
The rest of this [segment] discusses how the Nimrod routing and addressing
architecture interacts with the rest of the internetwork layer, and what
requirements it has upon the internetwork layer protocol's packet format.
Here are a couple of long messages which describe topics which aren't covered
in detail elsewhere.
New Datagram Mode, December 1993
After a fair amount of time had been put into the project, we came up with a
much better way to handle what we call "datagrams" (which is our term for
packets which aren't part of a long-term flow, but rather belong to short
transactions - perhaps only one packet - for which it is extremely
inefficient to do a full flow setup). This message introduces and describes
Flows Needed for NDM, January 1994
This message discusses how many DMF's (flows used to support New Datagram
Mode) an average router needs.
Spacing: A new attribute of graphs, August 1995
This message discusses a new attribute of graphs, one important to routing
(which I called 'spacing' - it has since been rediscovered, and given another
Eureka! F=ma for Access Control routing, August 1987
This is the message which started the whole ball rolling: while typing
it (in the second section, to be exact), the light bulb for the key idea
in the path which led to Nimrod went off in my head (about how when you
distribute maps, one can delay computing a path until it's needed). It's so
nice to have a key moment in the history documented so clearly for posterity!
The second part of the architecture, source routing, was added very soon
afterward (to prevent loops, when new attributes are added, but not all nodes
Back to JNC's home page
© Copyright 2000-2011 by J. Noel Chiappa
Last updated: 29/September/2011