rfc1574.txt

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

Network Working Group                                           S. Hares
Request for Comments: 1574                                  Merit/NSFNET
Obsoletes: 1139                                             C. Wittbrodt
Category: Informational                      Stanford University/BARRNet
                                                           February 1994


                  Essential Tools for the OSI 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 specifies the following three necessary tools to debug
   problems in the deployment and maintenance of networks using ISO 8473
   (CLNP):

      - ping or OSI Echo function
      - traceroute function which uses the OSI Echo function
      - routing table dump function

   These CLNS tools are the basics required for hosts and routers for
   CLNS network support. It is intended that this document specify the
   most basic support level required for CLNS hosts and routers.

   To support some of the needed tools (ping and traceroute) this memo
   specifies the mechanism specified in RFC 1575 [3].

Table of Contents

   Section 1. Conventions .......................................  2
   Section 2. Introduction ......................................  2
   Section 3. Specification .....................................  2
   Section 3.1 Ping .............................................  3
   Section 3.1.1 Protocol Support ...............................  3
   Section 3.1.2 Functions supported by the ping utility ........  3
   Section 3.2 Traceroute .......................................  3
   Section 3.2.1 Basic Traceroute ...............................  4
   Section 3.2.2 Use of Partial Source route in traceroute ......  5
   Section 3.2.3 Information needed from a Traceroute utility ...  6
   Section 3.3 OSI routing table dump ...........................  6
   Section 3.4 MIB variables available via SNMP .................  7
   Section 3.4.1 Summary of MIB Variables .......................  8
   Section 3.4.2 ASN.1 Syntax for these MIB variables ...........  8



Hares & Wittbrodt                                               [Page 1]

RFC 1574          Essential Tools for the OSI Internet     February 1994


   Section 4. OSI HOST.txt format ............................... 10
   Section 5. Acknowledgements .................................. 11
   Section 6. References ........................................ 12
   Section 7. Security Considerations ........................... 12
   Section 8. Author's Addresses ................................ 13

1.  Conventions

   The following language conventions are used in the items of
   specification in this document:

      o MUST, SHALL, or MANDATORY -- the item is an absolute
        requirement of the specification.

      o SHOULD or RECOMMENDED -- the item should generally be followed
        for all but exceptional circumstances.

      o MAY or OPTIONAL -- the item is truly optional and may be
        followed or ignored according to the needs of the implementor.

2.  Introduction

   Currently in the Internet, OSI protocols are being used more and
   more.  As the network managers of an Internet once predominantly a
   TCP/IP network began deploying parts of the emerging OSI Internet, it
   became apparent that network layer OSI network debugging tools were
   almost nonexistent.  When such tools existed, different
   implementations didn't work together.

   As stated in RFC 1575, a simple network layer mechanism is necessary
   to allow systems to be probed to test network layer integrity.  For
   the purposes of running OSI networks the authors of this document
   believe that other tools are necessary too.  Other tools described
   below are an echo function, a traceroute function, and a routing
   table dump.  What this document defines is the minimum subset of
   tools that are necessary to allow for the debugging of network
   problems.

3.  Specification

   This document's purpose is to specify a standard ping, traceroute,
   and OSI routing table dumping mechanisms for use for the ISO 8473
   (CLNP) protocol in the OSI Internet.  A detailed description of the
   specified mechanisms is below.  These mechanism MUST be available on
   every router (inter mediate system) or host (end system) that
   provides OSI service for the Internet.  These three functions are the
   basic tool set for the OSI network layer for the Internet.




Hares & Wittbrodt                                               [Page 2]

RFC 1574          Essential Tools for the OSI Internet     February 1994


3.1.  Ping

3.1.1.  Protocol Support

   The long term echo mechanism, as described in 1575, requires the use
   of two new type values in the packet header of the ISO 8473 Network
   Protocol Data Units (NPDUs), or preferably packets.  The two values
   are:

      1E(hex) - for the echo-request Selector and,
      1F(hex)  - for the echo-response Selector.

   Nodes which support ISO 8473 but do not support these two new values
   (for the type code option field in the header of an ISO 8473 packet)
   MUST send back an error packet if the ERROR report flag is set in the
   packet.

   To support a ping function for ISO 8473, all end systems (hosts) and
   intermediate systems (routers) MUST support the "long term" echo
   function as defined by RFC 1575 [3] AND also set the ERROR report
   flag in the 8473 header.

   The setting of the ERROR report flag is required because this allows
   a way for a compliant host or router to ping a non-compliant host or
   router.  When a non-complaint host or router receives a "ping" packet
   with the new type function (Echo Request Selector), it MUST attempt
   to return an ISO 8473 error packet to the originating host, thus
   showing reachability.

3.1.2.  Functions supported by the ping utility

   A ping utility MUST be able to provide the Round trip time of each
   packet, plus the average minimum and maximum RTT over several ping
   packets.  When an error packet is received by the node, the ping
   utility MUST report the error code to the user.

3.2.  Traceroute

   The CLNP trace is similar to the ping utility except that it utilizes
   the "Lifetime" field in the ISO 8473 packet.  Hosts and routers that
   support OSI MUST also support CLNP trace.  The "Lifetime" field
   serves the same function as the Time To Live (TTL) field does in an
   IP packet.  A node (router or host) cannot forward ISO 8473 packet
   with a value for the Lifetime of zero.  If the ERROR REPORT flag is
   set in the ISO 8473 packet, an error packet, will be returned to the
   originator of the packet.





Hares & Wittbrodt                                               [Page 3]

RFC 1574          Essential Tools for the OSI Internet     February 1994


3.2.1.  Basic Traceroute

   If a ISO 8473 echo-request packet is sent with "Lifetime" field value
   of 1, the first hop node (router or end system) will return an error
   packet to the originator the packet.  If the first hop node supports
   the echo-request type field the error code will be either:

      A0 (hex) - Lifetime Expired while Data Unit in Transit
      A1 (hex) - Lifetime Expired during Re-assembly

   If the first hop node does not support echo-request type field, the
   error code will be:

      B0 (hex) - Unsupported Option not Specified.

   When trying to trace a route to a remote node, the destination
   address in the echo-request packet sent should be this remote
   destination.  By using increasing values in the "Lifetime" field a
   route can be traced through the network to the remote node.  This
   traceroute function should be implemented on each system (host or
   router) to allow a user to trace a network path to a remote host or
   router.

   The error message is used as evidence of the reachability and
   identity of the first hop.  The originator then sends a packet with a
   "lifetime" field value of 2.  The first hop decrements the "Lifetime"
   and because the "Lifetime" is still greater than 0, it forwards it
   on.  The second hop decrements the "Lifetime" field value and sends
   an error packet (ER NPDU) with one of the two "Lifetime Expired"
   error codes listed above to the originator.  This sequence is
   repeated until either:

      - the remote host is reached an either an echo-response packet is
        sent back or (for nodes that do not have the required Echo
        support) an error packet is sent back, or

      - the an error packet is received with error code (B0) indicating
        that a node will not pass the echo-response packet, or

      - an error packet is received with one of the following errors:

      80(hex)  - Destination Address Unreachable
      81(hex)  - Destination Address Unknown.

   If any of the following Error codes are received in an error packet,
   a second packet should be sent by the originating node:





Hares & Wittbrodt                                               [Page 4]

RFC 1574          Essential Tools for the OSI Internet     February 1994


             CodeReason from 8473
             -----------------------------
             00(hex)  - Reason not specified
             01(hex)  - Protocol procedure error
             02(hex)  - Incorrect checksum
             03(hex)  - Packet Discarded due to Congestion
             04(hex)  - Header Syntax Error (cannot be parsed)
             05(hex)  - Segmentation needed but not permitted
             06(hex)  - Incomplete packet received
             07(hex)  - Duplicate Option
             B1(hex)  - Unsupported Protocol Version
             B2(hex)  - Unsupported Security Option
             B3(hex)  - Unsupported Source Routeing Option
             B4(hex)  - Unsupported Recording of Route Option
             C0(hex)  - Reassembly Interface

   If one of these error is detected, an error value should be returned
   to the user.  More than one echo packet, may be sent at a "Lifetime"
   value.  The number of additional echo packets is left up to the
   implementation of this traceroute function.

   If one of the following errors is received, AND "partial source
   route" is not specified in the echo-request packets, send a second
   echo-request packet to the destination at a "Lifetime" value:

             Code      Reason from 8473
             --------------------------------
             90(hex)   Unspecified Source Routeing Error
             91(hex)   Syntax Error in Source Routeing Field
             92(hex)   Unknown Address in Source Routeing Field
             93(hex)   Path not Acceptable

   (The echo-request packet may have been damaged while traversing
   through the network.)

3.2.2.  Use of Partial Source route in traceroute

   The current IP traceroute has a 3rd party or "loose source route"
   function.  The ISO 8473 protocol also supports a "partial source
   routeing" function.  However, if a node (router or host) does not
   support the "partial source routing" function an ISO 8473 packet gets
   passed along the path "exactly as though the function has not been
   selected.  The packet shall not be discarded for this reason." [2]

   In order utilize the partial source route function in the OSI
   traceroute, a node must set the "source routeing" option and "partial
   source routeing" parameter within that option.  A 3rd party, or
   "loose source route" traceroute function requires that a node send an



Hares & Wittbrodt                                               [Page 5]

RFC 1574          Essential Tools for the OSI Internet     February 1994


   echo-request packet with the "loose source routeing" field set. The
   functioning of the 3rd party/"loose source route" traceroute is the
   same except the following errors cause the traceroute to be
   terminated:

             Code      Reason from ISO 8473
             --------------------------------------------------
             92 Unknown Address in Source Routeing Field
             93 Path not Acceptable

   These errors may indicate a problem with the "loose source route"
   listed in the echo-request packet for this destination.  Additional
   packets with the same lifetime will only repeat this error.  These
   errors should be reported to the user of the traceroute function.

3.2.3.  Information needed from a Traceroute utility

   A traceroute utility should provide the following information to the
   user:

      - the identity of systems that comprise the path or route
        to the destination (the identifiers are called Network
        Entity Titles or NETs in OSI and ISO 8473)

      - ping times (in Round trip times) for each
        hop in the path,

      - error codes from error packet received as a
        response to the an echo-request packet, and

      - any other error conditions encountered
        by traceroute.

3.3.  OSI routing table dump

   Each OSI host (end system) or router (intermediate system) MUST be
   able to dump any of its routing tables.  Routing tables may come from
   the:

             a.) the ES-IS information
             b.) static
             c.) IS-IS
             d.) IDRP

   or any other source.

   Each system MUST be able to dump the routing table entries via some
   out of band mechanism. A method MUST exist to provide these. A show



Hares & Wittbrodt                                               [Page 6]

RFC 1574          Essential Tools for the OSI Internet     February 1994


   osi routes command SHOULD be created with the following options:

             - a        for all routes
             - esis     for es-is routes
             - isis     for is-is routes
             - idrp     for idrp routes
             - static   for static routes
             - other    for routes from other sources.

   In addition, routing tables SHOULD be available via either SNMP or
   CMIP.  The specification of CMIP variables are outside the scope of
   this specification.  Section 3.4 specifies the RFC 1238 MIB variables
   which MUST be available via SNMP.  These two variables simply allow
   the user to get some basic CLNS routing information.

   Please note that not all the information requested is available via
   the CLNS MIB.  Due to this fact, it is anticipated that additional
   work on a CLNS MIB will be done in the future.  When a new MIB is
   written, it is anticipated that this document will be updated to
   include the additional MIB variables to collect such things as the
   ES-IS cache.

3.4.  MIB variables available via SNMP