IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture
RFC 1753

 
Document Type RFC - Informational (December 1994; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1753 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         N. Chiappa
Request for Comments: 1753                                 December 1994
Category: Informational

                      IPng Technical Requirements
           Of the Nimrod Routing and Addressing Architecture

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document was submitted to the IETF IPng area in response to RFC
   1550.  Publication of this document does not imply acceptance by the
   IPng area of any ideas expressed within.  Comments should be
   submitted to the big-internet@munnari.oz.au mailing list.

   This document presents the requirements that the Nimrod routing and
   addressing architecture has upon the internetwork layer protocol. To
   be most useful to Nimrod, any protocol selected as the IPng should
   satisfy these requirements. Also presented is some background
   information, consisting of i) information about architectural and
   design principles which might apply to the design of a new
   internetworking layer, and ii) some details of the logic and
   reasoning behind particular requirements.

1. Introduction

   It is important to note that this document is not "IPng Requirements
   for Routing", as other proposed routing and addressing designs may
   need different support; this document is specific to Nimrod, and
   doesn't claim to speak for other efforts.

   However, although I don't wish to assume that the particular designs
   being worked on by the Nimrod WG will be widely adopted by the
   Internet (if for no other reason, they have not yet been deployed and
   tried and tested in practise, to see if they really work, an
   absolutely necessary hurdle for any protocol), there are reasons to
   believe that any routing architecture for a large, ubiquitous global
   Internet will have many of the same basic fundamental principles as
   the Nimrod architecture, and the requirements that these generate.

Chiappa                                                         [Page 1]
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                                                         [Page 2]
Show full document text