rfc1707.txt

RFC 的详细文档！

Network Working Group:                                       M. McGovern
Request for Comments: 1707                              Sunspot Graphics
Category: Informational                                       R. Ullmann
                                           Lotus Development Corporation
                                                            October 1994


              CATNIP: Common Architecture for the Internet

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.

Executive Summary

   This paper describes a common architecture for the network layer
   protocol. The Common Architecture for Next Generation Internet
   Protocol (CATNIP) provides a compressed form of the existing network
   layer protocols. Each compression is defined so that the resulting
   network protocol data units are identical in format. The fixed part
   of the compressed format is 16 bytes in length, and may often be the
   only part transmitted on the subnetwork.

   With some attention paid to details, it is possible for a transport
   layer protocol (such as TCP) to operate properly with one end system
   using one network layer (e.g. IP version 4) and the other using some
   other network protocol, such as CLNP. Using the CATNIP definitions,
   all the existing transport layer protocols used on connectionless
   network services will operate over any existing network layer
   protocol.

   The CATNIP uses cache handles to provide both rapid identification of
   the next hop in high performance routing as well as abbreviation of
   the network header by permitting the addresses to be omitted when a
   valid cache handle is available. The fixed part of the network layer
   header carries the cache handles.






McGovern & Ullmann                                              [Page 1]

RFC 1707                         CATNIP                     October 1994


   The cache handles are either provided by feedback from the downstream
   router in response to offered traffic, or explicitly provided as part
   of the establishment of a circuit or flow through the network. When
   used for flows, the handle is the locally significant flow
   identifier.

   When used for circuits, the handle is the layer 3 peer-to-peer
   logical channel identifier, and permits a full implementation of
   network-layer connection-oriented service if the routers along the
   path provide sufficient features. At the same time, the packet format
   of the connectionless service is retained, and hop by hop fully
   addressed datagrams can be used at the same time. Any intermediate
   model between the connection oriented and the connectionless service
   can thus be provided over cooperating routers.

CATNIP Objectives

   The first objective of the CATNIP is a practical recognition of the
   existing state of internetworking, and an understanding that any
   approach must encompass the entire problem. While it is common in the
   IP Internet to dismiss the ISO with various amusing phrases, it is
   hardly realistic. As the Internet moves into the realm of providing
   real commercial infrastructure, for telephone, cable television, and
   the myriad other mundane uses, compliance with international
   standards is an imperative.

   The argument that the IETF need not (or should not) follow existing
   ISO standards will not hold. The ISO is the legal standards
   organization for the planet. Every other industry develops and
   follows ISO standards. There is (no longer) anything special about
   computer software or data networking.

   ISO convergence is both necessary and sufficient to gain
   international acceptance and deployment of IPng. Non-convergence will
   effectively preclude deployment.

   The CATNIP integrates CLNP, IP, and IPX. The CATNIP design provides
   for any of the transport layer protocols in use, for example TP4,
   CLTP, TCP, UDP, IPX and SPX to run over any of the network layer
   protocol formats: CLNP, IP (version 4), IPX, and the CATNIP.

Incremental Infrastructure Deployment

   The best use of the CATNIP is to begin to build a common Internet
   infrastructure. The routers and other components of the common system
   are able to use a single consistent addressing method, and common
   terms of reference for other aspects of the system.




McGovern & Ullmann                                              [Page 2]

RFC 1707                         CATNIP                     October 1994


   The CATNIP is designed to be incrementally deployable in the strong
   sense: you can plop a CATNIP system down in place of any existing
   network component and continue to operate normally with no
   reconfiguration.  (Note: not "just a little". None at all. The number
   of "little changes" suggested by some proposals, and the utterly
   enormous amount of documentation, training, and administrative effort
   then required, astounds the present authors.) The vendors do all of
   the work.

   There are also no external requirements; no "border routers", no
   requirement that administrators apply specific restrictions to their
   network designs, define special tables, or add things to the DNS.
   When the end users and administrators fully understand the combined
   system, they will want to operate differently, but in no case will
   they be forced. Not even in small ways. Networks and end user
   organizations operate under sufficient constraints on deployment of
   systems anyway; they do not need a new network architecture adding to
   the difficulty.

   Typically deployment will occur as part of normal upgrade revisions
   of software, and due to the "swamping" of the existing base as the
   network grows. (When the Internet grows by a factor of 5, at least
   80% will then be "new" systems.) The users of the network may then
   take advantage of the new capabilities. Some of the performance
   improvements will be automatic, others may require some
   administrative understanding to get to the best performance level.

   The CATNIP definitions provide stateless translation of network
   datagrams to and from CATNIP and, by implication, directly between
   the other network layer protocols. A CATNIP-capable system
   implementing the full set of definitions can interoperate with any
   existing protocol. Various subsets of the full capability may be
   provided by some vendors.

No Address Translation

   Note that there is no "address translation" in the CATNIP
   specification.  (While it may seem odd to state a negative objective,
   this is worth saying as people seem to assume the opposite.) There
   are no "mapping tables", no magic ways of digging translations out of
   the DNS or X.500, no routers looking up translations or asking other
   systems for them.

   Addresses are modified with a simple algorithmic mapping, a mapping
   that is no more than using specific prefixes for IP and IPX
   addresses. Not a large set of prefixes; one prefix. The entire
   existing IP version 4 network is mapped with one prefix and the IPX
   global network with one other prefix. (The IP mapping does provide



McGovern & Ullmann                                              [Page 3]

RFC 1707                         CATNIP                     October 1994


   for future assignment of other IANA/IPv4 domains that are disjoint
   from the existing one.)

   This means that there is no immediate effect on addresses embedded in
   higher level protocols.

   Higher level protocols not using the full form (those native to IP
   and IPX) will eventually be extended to use the full addressing to
   extend their usability over all of the network layers.

No Legacy Systems

   The CATNIP leaves no systems behind: with no reconfiguration, any
   system presently capable of IP, CLNP, or IPX retains at least the
   connectivity it has now.  With some administrative changes (such as
   assigning IPX domain addresses to some CLNP hosts for example) on
   other systems, unmodified systems may gain significant connectivity.
   IPX systems with registered network numbers may gain the most.

Limited Scope

   The CATNIP defines a common network layer packet format and basic
   architecture. It intentionally does not specify ES-IS methods,
   routing, naming systems, autoconfiguration and other subjects not
   part of the core Internet wide architecture. The related problems and
   their (many) solutions are not within the scope of the specification
   of the basic common network layer.

Existing Addresses and Network Numbers

   The Internet's version 4 numbering system has proven to be very
   flexible, (mostly) expandable, and simple.  In short: it works.
   However, there are two problems. Neither was considered serious when
   the CATNIP was first developed in 1988 and 1989, but both are now of
   major concern:


   o The division into network, and then subnet, is insufficient.
     Almost all sites need a network assignment large enough to
     subnet. At the top of the hierarchy, there is a need to assign
     administrative domains.

   o As bit-packing is done to accomplish the desired network
     structure, the 32-bit limit causes more and more aggravation.

   Another major addressing system used in open internetworking is the
   OSI method of specifying Network Service Access Points (NSAPs). The
   NSAP consists of an authority and format identifier, a number



McGovern & Ullmann                                              [Page 4]

RFC 1707                         CATNIP                     October 1994


   assigned to that authority, an address assigned by that authority,
   and a selector identifying the next layer (transport layer) protocol.
   This is actually a general multi-level hierarchy, often obscured by
   the details of specific profiles. (For example, CLNP doesn't specify
   20 octet NSAPs, it allows any length. But various GOSIPs profile the
   NSAP as 20 octets, and IS-IS makes specific assumptions about the
   last 1-8 octets. And so on.)

   The NSAP does not directly correspond to an IP address, as the
   selector in IP is separate from the address. The concept that does
   correspond is the NSAP less the selector, called the Network Entity
   Title or NET. (An unfortunate acronym, but one we will use to avoid
   repeating the full term.) The usual definition of NET is an NSAP with
   the selector set to 0; the NET used here omits the 0 selector.

   There is also a network numbering system used by IPX, a product of
   Novell, Inc. (referred to from here on as Novell) and other vendors
   making compatible software. While IPX is not yet well connected into
   a global network, it has a larger installed base than either of the
   other network layers.

Network Layer Address

   The network layer address looks like:

      +----------+----------+---------------+---------------+
      |  length  |   AFI    |  IDI ...      | DSP ...       |
      +----------+----------+---------------+---------------+

   The fields are named in the usual OSI terminology although that leads
   to an oversupply of acronyms. Here are more detailed descriptions of
   each field:

   length: the number of bytes (octets) in the remainder of the
           address.

   AFI: the Authority and Format Identifier. A single byte
        value, from a set of well-known values registered by
        ISO, that determines the semantics of the IDI field

   IDI: the Initial Domain Identifier, a number assigned by the
        authority named by the AFI, formatted according to the
        semantics implied by the AFI, that determines the
        authority for the remainder of the address.

   DSP: Domain Specific Part, an address assigned by the
        authority identified by the value of the IDI.




McGovern & Ullmann                                              [Page 5]

RFC 1707                         CATNIP                     October 1994


   Note that there are several levels of authority. ISO, for example,
   identifies (with the AFI) a set of numbering authorities (like X.121,
   the numbering plan for the PSPDN, or E.164, the numbering plan for
   the telephone system). Each authority numbers a set of organizations
   or individuals or other entities. (For example, E.164 assigns
   16172477959 to me as a telephone subscriber.)

   The entity then is the authority for the remainder of the address. I
   can do what I please with the addresses starting with (AFI=E.164)
   (IDI=16172477959). Note that this is a delegation of authority, and
   not an embedding of a data-link address (the telephone number) in a
   network layer address. The actual routing of the network layer
   address has nothing to do with the authority numbering.