rfc1162.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 2,617 行 · 第 1/5 页
TXT
2,617 行
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 }
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?