rfc1070.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

NSAP-Address Format

   The OSI internetwork described here will form one routing domain,
   with one form of NSAP address recognized by all level 1 routers in
   this domain.  Other address formats may be agreed upon in later
   editions of this memo.

   The address format to be used in this experiment is that specified in
   RFC 1069.  According to RFC 1069, the low-order portion of the Domain
   Specific Part of the NSAP address may vary depending on the
   conventions of the particular routing domain.  For the purposes of
   this experiment, we shall use the following address format:






Hagens, Hall, & Rose                                            [Page 6]

RFC 1070                  Experimental OSI Net             February 1989


                        Address Format for EON
     Octet    Value         Meaning
     -------- ------------- ----------------------------------------
     1        47            Authority and Format Identifier
     2,3      00, 06        International Code Designator
     4        3             Version Number
     5,6      0             Global Area Number, see RFC 1069
     7,8      RDN           Routing Domain Number, assigned by IANA
     9-11     0             Pad
     12,13    0             LOC-AREA, see below
     14,15    0             unused
     16-19    A.B.C.D       Internet address
     20                     NSAP Selector, assigned IANA

      Note: It is our desire that the address format used by EON be
      consistent with RFC 1069.  To that end, the address format
      proposed by this RFC may change as future editions of RFC 1069
      become available.

   The mapping between NSAP-addresses and SNPA-addresses (Internet
   addreses) on the proposed IP subnet is straightforward.  The SNPA-
   address is embeded in the NSAP-address.

   There are several ways in which the LOC-AREA field could be used.

   (1) Assign local areas, administered by the Internet Assigned Numbers
       Authority (IANA).  The advantage of this is that it permits
       experimentation with area routing.  The disadvantage is that it
       will require an additional directory service to map host names to
       NSAP-addresses.  We would like to use the existing domain name
       servers to derive Internet addresses from names, and we would
       like NSAP-addresses to be derivable from the Internet addresses
       alone.

   (2) Have one local area in the EON, with LOC-AREA value 0.  This
       would eliminate the problem of name-toNSAP-address binding, but
       would not permit experimentation with area routing.  It would
       not, however preclude the use of areas later, for example, when
       OSI directory services are widely available.

   (3) Make the local area a simple function of the Internet address.
       The advantage of this is that it would permit experimentation
       with area addressing without requiring additional directory
       services, but the areas derived would not be under the control of
       the experimenters and may not correspond to anything useful or
       meaningful for the purposes of this experiment.

   We believe that initially, the preferred alternative is to use only



Hagens, Hall, & Rose                                            [Page 7]

RFC 1070                  Experimental OSI Net             February 1989


   zero-valued local areas.  Later editions of this memo may contain
   proposals for use of the local area field, when the IS-IS proposal is
   more mature and perhaps when OSI directory services are in use among
   experimenters.

   The value of the high-order portion of the DSP will be set in
   accordance with RFC 1069.

Other NSAP-Address Formats

   PDUs carrying NSAP-addresses of other formats can be routed through
   this domain.  This is the job of the level 2 routers, described in
   the IS-IS document.

Multicast Addresses on the IP Subnet

   The ES-IS and IS-IS routing exchange protocols assume that broadcast
   subnetworks support two multicast addresses: one for all ESs and the
   other for all ISs.  While one could obviate this issue by treating
   the IP subnet as a general topology subnetwork or as a set of point-
   to-point links, it is also desirable to treat the IP subnet as a
   broadcast subnetwork for the purpose of testing those parts of an
   implementation that run over broadcast subnets.  A participating
   implementor not having access to several local machines running the
   OSI CLNL may test the protocols over the IP subnet as if the IP
   subnet were a broadcast subnet.

   The multicasting assumed by the OSI CLNL can be simulated by a small
   sublayer lying between the OSI CLNL and the IP subnet layer.  For the
   purpose of this discussion, call this sublayer an SNAcP, a SubNetwork
   Access Protocol, in OSI argot.  In each system the SNAcP caches a
   table of the Internet addresses of systems that it considers to be
   reachable in one ISO 8473-hop over the IP subnet.  These are called
   "core" systems.  In this sense, the use of the cache simulates a set
   of links over which a system will send ISO configuration messages (ES
   Hello, IS Hello, etc.) when it comes up.  As a local matter, the
   table of core systems may or may not expand during the system's
   lifetime, in response to configuration messages from other core
   systems.

   On the outgoing path, the SNAcP accepts an ISO-gram and a parameter
   indicating the intended use of this ISO-gram: send to a single
   system, to all ESs, to all ISs, or to all systems.  If the indended
   destination is a single system, the ISO-gram is sent only to its
   destination.  Otherwise, the SNAcP makes a copy of the ISO-gram for
   each of the SNPA-addresses in the cache, effecting a broadcast to all
   participating systems.  Before passing an ISO-gram to the IP subnet
   layer, the SNAcP prepends an SNAcP header to each outgoing ISO-gram.



Hagens, Hall, & Rose                                            [Page 8]

RFC 1070                  Experimental OSI Net             February 1989


   This header will take the form:

                          SNAcP Header Format
       Octet   Value                       Meaning
       --------------------------------------------------------
       1       01            Version number
       --------------------------------------------------------
       2                     Semantics of address:
               00            Not a multicast address
               01            All ESs
               02            All ISs
               03            Broadcast
       --------------------------------------------------------
       3,4                   OSI checksum as defined in ISO 8473

   The SNAcP header has three fields, a version number field, a
   semantics field, and a checksum field.  The version number will take
   the value 01.  The checksum field will take the two octet ISO
   (Fletcher) checksum of the SNAcP header.  The checksum algorithm is
   described in ISO 8473.

   The semantics field will take one of 4 values, indicating "all ESs",
   "all ISs", "broadcast", or "not a multicast address".  The value of
   the semantics field is determined by a parameter passed to the SNAcP
   by the calling OSI network entity.  A participant in the experiment
   may test the OSI network layer over a set of point-to-point links by
   choosing not to use the multicast capabilities provided by the SNAcP
   on the outgoing path.

   On the incoming path, the SNAcP inspects the SNAcP header and decides
   whether or not to accept the ISO-gram.  If it accepts the ISO-gram,
   the SNAcP removes the SNAcP header and passes the ISO-gram to the OSI
   CLNL, otherwise, it discards the ISO-gram.  The SNAcP will always
   accept ISO-grams with SNAcP headers indicating "not a multicast
   address" (value zero in the semantics field) and "broadcast" (value
   03).  Whether an SNAcP will accept ISO-grams for either of the two
   multicast groups "all ESs" (value 1) and "all ISs" (value 2) will
   depend on local configuration information.  If the system on which
   the SNAcP resides is configured as an end system, it will accept
   ISO-grams destined for "all ESs" and if it is configured as an
   intermediate system, it will accept ISO-grams destined for "all ISs".

   A participant who is testing the OSI network layer over a set of
   point-to-point links will accept ISO-grams according to these rules
   as well.

   Consideration was given to making the SNAcP extensible by making the
   semantics and checksum fields variable-length parameters, in the



Hagens, Hall, & Rose                                            [Page 9]

RFC 1070                  Experimental OSI Net             February 1989


   manner of ISO 8473.  We feel that the presence of a version number
   provides sufficient extensibility.

Errors on the IP subnet

   The IP subnet layer may receive ICMP messages and may pass error
   indications to the SNAcP layer as a result of having received these
   ICMP messages.  It is assumed that in this context, the IP subnet
   will handle ICMP messages in the same way that it handles them in any
   other context.  For example, upon receipt of an ICMP echo message,
   the IP subnet will respond with an ICMP echo reply, and the SNAcP
   need not be informed of the receipt of the ICMP echo message.
   Certain ICMP messages such as source quench are likely to produce an
   error indication to all layers using the IP subnet.  The actions
   taken by the SNAcP for these indications is purely a local matter,
   however the following actions are suggested.

                Suggested SNAcP Actions in Response to
                    ICMP-related Error Indications
         ICMP message type          Action taken by the SNAcP
      -----------------------------------------------------------
      Destination unreachable,   If the remote address is present
      Parameter problem,         in the cache of core systems'
      Time exceeded              addresses, mark it unusable.
                                 Inform network management.
      -----------------------------------------------------------
      Source quench              If the remote address is present
                                 in the cache of core systems'
                                 addresses, mark the remote
                                 address as unusable and set a
                                 timer for a time after which
                                 the address becomes usable
                                 again.
                                 Inform network management.
      -----------------------------------------------------------
      All others                 Ignored by the SNAcP layer.


   To "inform network management" may mean to print a message on the
   system console, to inform a local process, to increment a counter, to
   write a message in a log file, or it may mean to do nothing.

   The effect of marking a cached address as unusable is as follows.
   When the SNAcP attempts to broadcast or multicast an ISO-gram,
   addresses in the cache that are marked as unusable are ignored.  When
   the SNAcP attempts to send a non-multicast ISO-gram to an unusable
   cached address, the SNAcP returns an error indication to the OSI
   CLNL.  In this way, when the OSI CLNL uses the SNAcP to simulate a



Hagens, Hall, & Rose                                           [Page 10]

RFC 1070                  Experimental OSI Net             February 1989


   set of point-to-point links, it is notified when a link fails, but
   when the OSI CLNL uses the SNAcP to simulate a multicast subnet, it
   is not notified when one system on the subnet goes down.

Use of UDP/IP in Lieu of IP

   In addition to using IP directly, for testing purposes it may be
   useful to support the OSI CLNL over the User Datagram Protocol (UDP).
   This is because some implementors do not have direct access to IP,
   but do have access to the UDP.  For example, an implementor may have
   an a binary license for an operating system that provides TCP/IP and
   UDP/IP, but no direct access to IP.  These implementors may
   participate in a parallel experiment, called EON-UDP, by using UDP/IP
   as a subnetwork instead of using the IP subnet.  In this case, the
   OSI NPDU (after fragmentation, if applicable) will be placed in the
   data portion of a UDP datagram.  UDP port 147 (decimal) has been
   assigned for this purpose.  These participants will place an SNAcP
   between UDP and ISO 8473 rather than between IP and ISO 8473.  In all
   other respects, the EON-UDP experiment is identical to the EON
   experiment.

   Of course, network layers entities using the UDP/IP subnet will not
   interoperate directly with network layers entities using the IP
   subnet.  The procedures proposed in this memo do not prevent an
   implementor from building an EON to EON-UDP gateway, however the
   issues related to building and routing to such a gateway are not
   addressed in this memo.  This memo simply proposes two distinct
   parallel experiments for two groups of experimenters having different
   resources.

   The preferred method of experimentation is to use the IP subnet, in
   other words, EON.  The EON-UDP variant is intended for use only by
   those who cannot participate in EON.

Dissemination of Topological Information and Host Names

   The EON experiment simulates a logical topology that is not as
   connected as the underlying logical topology offered by the Internet.
   The topology of the IP subnet is, in effect, simulated by the SNAcP
   layer in each of the core systems.  Each of the core systems caches a
   list of the other core systems in the EON.  When a system boots, it
   needs some initial list of the participating core systems.  For this
   reason, a list of core systems will be maintained by the IANA.

   In addition, a list of all participating ESs will be maintained by
   the IANA.  This list is not necessary for the functioning of the EON
   network layer.  It is a convenience to the experimenters, and is
   meant for use by application layer software or human users.



Hagens, Hall, & Rose                                           [Page 11]

RFC 1070                  Experimental OSI Net             February 1989


   Two pairs of lists are kept, one for the EON and one for EON-UDP.

   core.EON  This is a list of SNPA-addresses of those systems
             that will be (logically) reachable via the IP subnet
             in one ISO 8473-hop from any other core system.  This
             does not mean that systems in this file are gateways
             or ISs.  They may be ESs, ISs or both.  A site may
             participate as a core system before its address is
             included in this file and distributed to other core
             systems, but under these circumstances other core systems
             will not know to send configuration messages (ESHs and
             ISHs) to the new site when coming up or rebooting.  The
             SNPA-addresses in this file will be ASCII strings of
             the form A.B.C.D, no more than one per line.
             White space (tabs, blanks) will be optional before
             A and after D.  A pound-sign (#) will indicate that