rfc1162.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 2,761 行 · 第 1/5 页

Network Working Group                                        Greg Satz
Request for Comments: 1162                         cisco Systems, Inc.
                                                             June 1990


               Connectionless Network Protocol (ISO 8473)
                                  and
              End System to Intermediate System (ISO 9542)
                      Management Information Base

                           Table of Contents

   1. Status of this Memo ..................................    1
   2. Historical Perspective................................    2
   3. Objects ..............................................    3
   3.1 Format of Definitions ...............................    3
   4. Object Definitions ...................................    4
   4.1 The CLNP Group ......................................    5
   4.1.1 The CLNP Interfaces table .........................   14
   4.1.2 The CLNP Routing table ............................   16
   4.1.3 The CLNP Address Translation Tables ...............   22
   4.2 The CLNP Error Group ................................   30
   4.3 The ESIS Group ......................................   47
   5. Definitions ..........................................   50
   6. Identification of OBJECT instances for use with  the
      SNMP .................................................   66
   6.1 clnpAddrTable Object Type Names .....................   67
   6.2 clnpRoutingTable Object Type Names ..................   67
   6.3 clnpNetToMediaTable Object Type Names ...............   68
   6.4 clnpMediaToNetTable Object Type Names ...............   68
   7. References ...........................................   69
   8. Security Considerations...............................   70
   9. Author's Address......................................   70

1.  Status of this Memo

   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   TCP/IP-based internets.

   This memo does not specify a standard for the Internet community.
   However, after experimentation, if sufficient consensus is reached in
   the Internet community, then a subsequent revision of this document
   may be placed in the Internet-standard MIB.

   Distribution of this memo is unlimited.





Satz                                                            [Page 1]

RFC 1162                        CLNS MIB                       June 1990


2.  Historical Perspective

   As reported in RFC 1052, IAB Recommendations for the Development of
   Internet Network Management Standards [1], a two-prong strategy for
   network management of TCP/IP-based internets was undertaken.  In the
   short-term, the Simple Network Management Protocol (SNMP), defined in
   RFC 1067, was to be used to manage nodes in the Internet community.
   In the long-term, the use of the OSI network management framework was
   to be examined.  Two documents were produced to define the management
   information: RFC 1065, which defined the Structure of Management
   Information (SMI), and RFC 1066, which defined the Management
   Information Base (MIB).  Both of these documents were designed so as
   to be compatible with both the SNMP and the OSI network management
   framework.

   This strategy was quite successful in the short-term: Internet-based
   network management technology was fielded, by both the research and
   commercial communities, within a few months.  As a result of this,
   portions of the Internet community became network manageable in a
   timely fashion.

   As reported in RFC 1109, Report of the Second Ad Hoc Network
   Management Review Group [2], the requirements of the SNMP and the OSI
   network management frameworks were more different than anticipated.
   As such, the requirement for compatibility between the SMI/MIB and
   both frameworks was suspended.  This action permitted the operational
   network management framework, based on the SNMP, to respond to new
   operational needs in the Internet community by producing MIB-II.

   In May of 1990, the core documents were elevated to "Standard
   Protocols" with "Recommended" status.  As such, the Internet-
   standard network management framework consists of: Structure and
   Identification of Management Information for TCP/IP-based internets,
   RFC 1155 [3], which describes how managed objects contained in the
   MIB are defined; Management Information Base for Network Management
   of TCP/IP-based internets, which describes the managed objects
   contained in the MIB, RFC 1156 [4]; and, the Simple Network
   Management Protocol, RFC 1157 [5], which defines the protocol used to
   manage these objects.

   Consistent with the IAB directive to produce simple, workable systems
   in the short-term, the list of managed objects defined in the
   Internet-standard MIB was derived by taking only those elements which
   are considered essential.  However, the SMI defined three
   extensibility mechanisms: one, the addition of new standard objects
   through the definitions of new versions of the MIB; two, the addition
   of widely-available but non-standard objects through the experimental
   subtree; and three, the addition of private objects through the



Satz                                                            [Page 2]

RFC 1162                        CLNS MIB                       June 1990


   enterprises subtree.  Such additional objects can not only be used
   for vendor-specific elements, but also for experimentation as
   required to further the knowledge of which other objects are
   essential.

   Since the publication of the Internet-standard MIB, experience has
   lead to a new document, termed MIB-II [6], being defined.

   This memo defines extensions to the MIB using the second method.  It
   contains definitions of managed objects used for experimentation.
   After experimentation, if sufficient consensus is reached in the
   Internet community, then a subsequent revision of this memo may be
   placed in the Internet-standard MIB.

3.  Objects

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
   defined in the SMI.  In particular, each object has a name, a syntax,
   and an encoding.  The name is an object identifier, an
   administratively assigned name, which specifies an object type.  The
   object type together with an object instance serves to uniquely
   identify a specific instantiation of the object.  For human
   convenience, we often use a textual string, termed the OBJECT
   DESCRIPTOR, to also refer to the object type.

   The syntax of an object type defines the abstract data structure
   corresponding to that object type.  The ASN.1 language is used for
   this purpose.  However, the SMI [3] purposely restricts the ASN.1
   constructs which may be used.  These restrictions are explicitly made
   for simplicity.

   The encoding of an object type is simply how that object type is
   represented using the object type's syntax.  Implicitly tied to the
   notion of an object type's syntax and encoding is how the object type
   is represented when being transmitted on the network.

   This SMI specifies the use of the basic encoding rules of ASN.1 [8],
   subject to the additional requirements imposed by the SNMP.

3.1.  Format of Definitions

   The next section contains the specification of all object types
   contained in the MIB.  Following the conventions of the companion
   memo, the object types are defined using the following fields:





Satz                                                            [Page 3]

RFC 1162                        CLNS MIB                       June 1990


          OBJECT:
          -------
               A textual name, termed the OBJECT DESCRIPTOR, for the
               object type, along with its corresponding OBJECT
               IDENTIFIER.

          Syntax:
               The abstract syntax for the object type, presented using
               ASN.1.  This must resolve to an instance of the ASN.1
               type ObjectSyntax defined in the SMI.

          Definition:
               A textual description of the semantics of the object
               type.  Implementations should ensure that their
               interpretation of the object type fulfills this
               definition since this MIB is intended for use in multi-
               vendor environments.  As such it is vital that object
               types have consistent meaning across all machines.

          Access:
               A keyword, one of read-only, read-write, write-only, or
               not-accessible.  Note that this designation specifies the
               minimum level of support required.  As a local matter,
               implementations may support other access types (e.g., an
               implementation may elect to permitting writing a variable
               marked herein as read-only).  Further, protocol-specific
               "views" (e.g., those implied by an SNMP community) may
               make further restrictions on access to a variable.

          Status:
               A keyword, one of mandatory, optional, obsolete, or
               deprecated.  Use of deprecated implies mandatory status.

4.  Object Definitions

               CLNS-MIB DEFINITIONS ::= BEGIN

               IMPORTS
                       experimental,  OBJECT-TYPE, Counter
                               FROM RFC1155-SMI;

               -- new type of NetworkAddress

               ClnpAddress ::=
                   [APPLICATION 5]
                       IMPLICIT OCTET STRING (SIZE (1..21))





Satz                                                            [Page 4]

RFC 1162                        CLNS MIB                       June 1990


               clns    OBJECT IDENTIFIER ::=   { experimental 1 }

               clnp    OBJECT IDENTIFIER ::=   { clns 1 }
               error   OBJECT IDENTIFIER ::=   { clns 2 }
               echo    OBJECT IDENTIFIER ::=   { clns 3 }
               es-is   OBJECT IDENTIFIER ::=   { clns 4 }

               END

   These objects can be used when the ISO Connectionless-mode Network
   Protocol [9] and End System to Intermediate System [10] protocols are
   present. No assumptions are made as to what underlying protocol is
   being used to carry the SNMP.

   This memo uses the string encoding of [11] to textually describe OSI
   addresses.

   The ASN.1 type ClnpAddress is used to denote an OSI address.  This
   consists of a string of octets.  The first octet of the string
   contains a binary value in the range of 0..20, and indicates the the
   length in octets of the NSAP.  Following the first octet, is the
   NSAP, expressed in concrete binary notation, starting with the most
   significant octet.  A zero- length NSAP is used as a "special"
   address meaning "the default NSAP" (analogous to the IP address of
   0.0.0.0).  Such an NSAP is encoded as a single octet, containing the
   value 0.

   All other NSAPs are encoded in at least 2 octets.

4.1.  The CLNP Group

   Implementation is experimental and is recommended for all systems
   that support a CLNP.


          OBJECT:
          -------
               clnpForwarding { clnp 1 }

          Syntax:
               INTEGER {
                    is(1),   -- entity is an intermediate system
                    es(2),   -- entity is an end system and does not
                                forward PDUs
               }

          Definition:
               The indication of whether this entity is active as an



Satz                                                            [Page 5]

RFC 1162                        CLNS MIB                       June 1990


               intermediate or end system. Only intermediate systems
               will forward PDUs onward that are not addressed to them.

          Access:
               read-write.

          Status:
               mandatory.


          OBJECT:
          -------
               clnpDefaultLifeTime { clnp 2 }

          Syntax:
               INTEGER

          Definition:
               The default value inserted into the Lifetime field of the
               CLNP PDU header of PDUs sourced by this entity.

          Access:
               read-write.

          Status:
               mandatory.


          OBJECT:
          -------
               clnpInReceives { clnp 3 }

          Syntax:
               Counter

          Definition:
               The total number of input PDUs received from all
               connected network interfaces running CLNP, including
               errors.

          Access:
               read-only.

          Status:
               mandatory.






Satz                                                            [Page 6]

RFC 1162                        CLNS MIB                       June 1990


          OBJECT:
          -------
               clnpInHdrErrors { clnp 4 }

          Syntax:
               Counter

          Definition:
               The number of input PDUs discarded due to errors in the
               CLNP header, including bad checksums, version mismatch,
               lifetime exceeded, errors discovered in processing
               options, etc.

          Access:
               read-only.

          Status:
               mandatory.


          OBJECT:
          -------
               clnpInAddrErrors { clnp 5 }

          Syntax:
               Counter

          Definition:
               The number of input PDUs discarded because the NSAP
               address in the CLNP header's destination field was not a
               valid NSAP to be received at this entity. This count
               includes addresses not understood.  For end systems, this
               is a count of PDUs which arrived with a destination NSAP
               which was not local.

          Access:
               read-only.

          Status:
               mandatory.


          OBJECT:
          -------
               clnpForwPDUs { clnp 6 }

          Syntax:
               Counter



Satz                                                            [Page 7]

RFC 1162                        CLNS MIB                       June 1990


          Definition:
               The number of input PDUs for which this entity was not
               the final destination and which an attempt was made to
               forward them onward.

          Access:
               read-only.

          Status:
               mandatory.


          OBJECT:
          -------
               clnpInUnknownNLPs { clnp 7 }

          Syntax:
               Counter

          Definition:
               The number of locally-addressed PDUs successfully
               received but discarded because the network layer protocol
               was unknown or unsupported (e.g., not CLNP or ES-IS).

          Access:
               read-only.

          Status:
               mandatory.


          OBJECT:
          -------
               clnpInUnknownULPs { clnp 8 }

          Syntax:
               Counter

          Definition:
               The number of locally-addressed PDUs successfully
               received but discarded because the upper layer protocol
               was unknown or unsupported (e.g., not TP4).

          Access:
               read-only.

          Status:
               mandatory.



Satz                                                            [Page 8]

RFC 1162                        CLNS MIB                       June 1990


          OBJECT:
          -------
               clnpInDiscards { clnp 9 }

          Syntax:
               Counter

          Definition:
               The number of input CLNP PDUs for which no problems were
               encountered to prevent their continued processing, but
               were discarded (e.g., for lack of buffer space). Note that
               this counter does not include any PDUs discarded while
               awaiting re-assembly.

          Access:
               read-only.

          Status:
               mandatory.


          OBJECT:
          -------
               clnpInDelivers { clnp 10 }

          Syntax:
               Counter

          Definition:
               The total number of input PDUs successfully delivered to
               the CLNS transport user.

          Access:
               read-only.

          Status:
               mandatory.


          OBJECT:
          -------
               clnpOutRequests { clnp 11 }

          Syntax:
               Counter

          Definition:
               The total number of CLNP PDUs which local CLNS user



Satz                                                            [Page 9]

RFC 1162                        CLNS MIB                       June 1990


               protocols supplied to CLNP for transmission requests.
               This counter does not include any PDUs counted in
               clnpForwPDUs.

          Access:
               read-only.

          Status:
               mandatory.


          OBJECT:
          -------
               clnpOutDiscards { clnp 12 }

          Syntax:
               Counter

          Definition:
               The number of output CLNP PDUs for which no other problem
               was encountered to prevent their transmission but were
               discarded (e.g., for lack of buffer space). Note this
               counter includes PDUs counted in clnpForwPDUs.

          Access:
               read-only.

          Status:
               mandatory.


          OBJECT:
          -------
               clnpOutNoRoutes { clnp 13 }

          Syntax:
               Counter

          Definition:
               The number of CLNP PDUs discarded because no route could
               be found to transmit them to their destination. This
               counter includes any PDUs counted in clnpForwPDUs.