RFC 1753 (rfc1753) - Page 2 of 18
IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture
Alternative Format: Original Text Document
RFC 1753 Nimrod Technical Requirements for IPng December 1994
While current day routing technologies do not yet have the
characteristics and capabilities that generate these requirements,
they also do not seem to be completely suited to routing in the
next-generation Internet. As routing technology moves towards what is
needed for the next generation Internet, the underlying fundamental
laws and principles of routing will almost inevitably drive the
design, and hence the requirements, toward things which look like the
material presented here.
Therefore, even if Nimrod is not the routing architecture of the
next-generation Internet, the basic routing architecture of that
Internet will have requirements that, while differing in detail, will
almost inevitably be similar to these.
In a similar, but more general, context, note that, by and large, the
general analysis of sections 3.1 ("Interaction Architectural Issues")
and 3.2 ("State and Flows in the Internetwork Layer") will apply to
other areas of a new internetwork layer, not just routing.
I will tackle the internetwork packet format first (which is
simpler), and then the whole issue of the interaction with the rest
of the internetwork layer (which is a much more subtle topic).
2. Packet Format
2.1 Packet Format Issues
As a general rule, the design philosophy of Nimrod is "maximize the
lifetime (and flexibility) of the architecture". Design tradeoffs
(i.e., optimizations) that will adversely affect the flexibility,
adaptability and lifetime of the design are not not necessarily wise
choices; they may cost more than they save. Such optimizations might
be the correct choices in a stand-alone system, where the replacement
costs are relatively small; in the global communication network, the
replacement costs are very much higher.
Providing the Nimrod functionality requires the carrying of certain
information in the packets. The design principle noted above has a
number of corollaries in specifying the fields to contain that
information.
First, the design should be "simple and straightforward", which means
that various functions should be handled by completely separate
mechanisms, and fields in the packets. It may seem that an
opportunity exists to save space by overloading two functions onto
one mechanism or field, but general experience is that, over time,
this attempt at optimization costs more, by restricting flexibility
and adaptability.
Chiappa