rfc1753.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/4 页

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 [e-mail] 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]

RFC 1753         Nimrod Technical Requirements for IPng    December 1994


   Second, field lengths should be specified to be somewhat larger than
   can conceivably be used; the history of system architecture is
   replete with examples (processor address size being the most
   notorious) where fields became too short over the lifetime of the
   system. The document indicates what the smallest reasonable
   "adequate" lengths are, but this is more of a "critical floor" than a
   recommendation. A "recommended" length is also given, which is the
   length which corresponds to the application of this principle. The
   wise designer would pick this length.

   It is important to now that this does *not* mean that implementations
   must support the maximum value possible in a field of that size. I
   imagine that system-wide administrative limits will be placed on the
   maximum values which must be supported. Then, as the need arises, we
   can increase the administrative limit. This allows an easy, and
   completely interoperable (with no special mechanisms) path to upgrade
   the capability of the network. If the maximum supported value of a
   field needs to be increased from M to N, an announcement is made that
   this is coming; during the interim period, the system continues to
   operate with M, but new implementations are deployed; while this is
   happening, interoperation is automatic, with no transition mechanisms
   of any kind needed. When things are "ready" (i.e., the proportion of
   old equipment is small enough), use of the larger value commences.

   Also, in speaking of the packet format, you first need to distinguish
   between the host-router part of the path, and the router-router part;
   a format that works OK for one may not do for another.

   The issue is complicated by the fact that Nimrod can be made to work,
   albeit not in optimal form, with information/fields missing from the
   packet in the host to "first hop router" section of the packet's
   path. The missing fields and information can then be added by the
   first hop router. (This capability will be used to allow deployment
   and operation with unmodified IPv4 hosts, although similar techniques
   could be used with other internetworking protocols.) Access to the
   full range of Nimrod capabilities will require upgrading of hosts to
   include the necessary information in the packets they exchange with
   the routers.

   Second, Nimrod currently has three planned forwarding modes (flows,
   datagram, and source-routed packets), and a format that works for one
   may not work for another; some modes use fields that are not used by
   other modes.  The presence or absence of these fields will make a
   difference.







Chiappa                                                         [Page 3]

RFC 1753         Nimrod Technical Requirements for IPng    December 1994


2.2 Packet Format Fields

   What Nimrod would like to see in the internetworking packet is:

   - Source and destination endpoint identification. There are several
     possibilities here.

     One is "UID"s, which are "shortish", fixed length fields which
     appear in each packet, in the internetwork header, which contain
     globally unique, topologically insensitive identifiers for either
     i) endpoints (if you aren't familiar with endpoints, think of them
     as hosts), or ii) multicast groups. (In the former instance, the
     UID is an EID; in the latter, a "set ID", or SID. An SID is an
     identifier which looks just like an EID, but it refers to a group
     of endpoints. The semantics of SID's are not completely defined.)
     For each of these 48 bits is adequate, but we would recommend 64
     bits. (IPv4 will be able to operate with smaller ones for a while,
     but eventually either need a new packet format, or the difficult
     and not wholly satisfactory technique known as Network Address
     Translators, which allows the contents of these fields to be only
     locally unique.)

     Another possibility is some shorter field, named an "endpoint
     selector", or ESEL, which contains a value which is not globally
     unique, but only unique in mapping tables on each end, tables which
     map from the small value to a globally unique value, such as a DNS
     name.

     Finally, it is possible to conceive of overall networking designs
     which do not include any endpoint identification in the packet at
     all, but transfer it at the start of a communication, and from then
     on infer it.  This alternative would have to have some other means
     of telling which endpoint a given packet is for, if there are
     several endpoints at a given destination. Some coordination on
     allocation of flow-ids, or higher level port numbers, etc., might
     do this.

   - Flow identification. There are two basic approaches here, depending
     on whether flows are aggregated (in intermediate switches) or not.
     It should be emphasized at this point that it is not yet known
     whether flow aggregation will be needed. The only reason to do it
     is to control the growth of state in intermediate routers, but
     there is no hard case made that either this growth will be
     unmanageable, or that aggregating flows will be feasible
     practically.






Chiappa                                                         [Page 4]

RFC 1753         Nimrod Technical Requirements for IPng    December 1994


     For the non-aggregated case, a single "flow-id" field will suffice.
     This *must not* use one of the two previous UID fields, as in
     datagram mode (and probably source-routed mode as well) the flow-id
     will be over-written during transit of the network. It could most
     easily be constructed by adding a UID to a locally unique flow-id,
     which will provide a globally unique flow-id. It is possible to use
     non-globally unique flow-ids, (which would allow a shorter length
     to this field), although this would mean that collisions would
     result, and have to be dealt with. An adequate length for the local
     part of a globally unique flow-id would be 12 bits (which would be
     my "out of thin air" guess), but we recommend 32. For a non-
     globally unique flow-id, 24 bits would be adequate, but I recommend
     32.

     For the aggregated case, three broad classes of mechanism are
     possible.

      - Option 1: The packet contains a sequence (sort of like a source
        route) of flow-ids. Whenever you aggregate or deaggregate, you
        move along the list to the next one. This takes the most space,
        but is otherwise the least work for the routers.

      - Option 2: The packet contains a stack of flow-ids, with the