📄 rfc1238.txt
字号:
Network Working Group G. Satz
Request for Comments: 1238 cisco Systems, Inc.
Obsoletes: RFC 1162 June 1991
CLNS MIB
for use with
Connectionless Network Protocol (ISO 8473)
and
End System to Intermediate System (ISO 9542)
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 is an Experimental Protocol for the
Internet community. Discussion and suggestions for improvement are
requested. Please refer to the current edition of the "IAB Official
Protocol Standards" for the standardization state and status of this
protocol. Distribution of this memo is unlimited.
Table of Contents
1. The Network Management Framework....................... 1
2. Objects ............................................... 2
2.1 Format of Definitions ................................ 2
3. Overview .............................................. 2
3.1 Textual Conventions .................................. 3
3.2 Changes from RFC 1162 ................................ 3
4. Definitions ........................................... 4
4.1 Textual Conventions .................................. 4
4.2 Groups in the CLNS MIB ............................... 4
4.3 The CLNP Group ....................................... 4
4.4 The CLNP Error Group ................................. 21
4.5 The ES-IS Group ...................................... 30
5. References ............................................ 31
6. Security Considerations ............................... 32
7. Author's Address....................................... 32
1. The Network Management Framework
The Internet-standard Network Management Framework consists of three
components. They are:
RFC 1155 which defines the SMI, the mechanisms used for describing
and naming objects for the purpose of management. RFC 1212
defines a more concise description mechanism, which is wholly
consistent with the SMI.
Satz [Page 1]
RFC 1238 CLNS MIB June 1991
RFC 1156 which defines MIB-I, the core set of managed objects for
the Internet suite of protocols. RFC 1213, defines MIB-II, an
evolution of MIB-I based on implementation experience and new
operational requirements.
RFC 1157 which defines the SNMP, the protocol used for network
access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
2. 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.
The SMI specifies the use of the basic encoding rules of ASN.1 [8],
subject to the additional requirements imposed by the SNMP.
2.1. Format of Definitions
Section 4 contains the specification of all object types contained in
this MIB module. The object types are defined using the conventions
defined in the SMI, as amended by the extensions specified in [9].
3. Overview
The objects defined in this MIB module are be used when the ISO
Connectionless-mode Network Protocol [10] and End System to
Satz [Page 2]
RFC 1238 CLNS MIB June 1991
Intermediate System [11] 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 [12] to textually describe OSI
addresses.
3.1. Textual Conventions
A new data type is introduced as a textual convention in this MIB
document. This textual conventions enhance the readability of the
specification and can ease comparison with other specifications if
appropriate. It should be noted that the introduction of this
textual convention has no effect on either the syntax nor the
semantics of any managed objects. The use of this is merely an
artifact of the explanatory method used. Objects defined in terms of
this methods are always encoded by means of the rules that define the
primitive type. Hence, no changes to the SMI or the SNMP are
necessary to accommodate this textual convention which are adopted
merely for the convenience of readers and writers in pursuit of the
elusive goal of clear, concise, and unambiguous MIB documents.
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 4 octets.
3.2. Changes from RFC 1162
Features of this MIB include:
(1) The managed objects in this document have been defined
using the conventions defined in the Internet-standard
SMI, as amended by the extensions specified in [9]. It
must be emphasized that definitions made using these
extensions are semantically identically to those in RFC
1162.
(2) The PhysAddress textual convention from MIB-II has been
introduced to represent media addresses.
(3) The clnpRoutingDiscards, clnpRouteMetric5, and
clnpRouteInfo objects have been defined.
Satz [Page 3]
RFC 1238 CLNS MIB June 1991
(4) The ClnpAddress type was mistakenly given a tag in RFC
1162. This error has been corrected.
4. Definitions
CLNS-MIB DEFINITIONS ::= BEGIN
IMPORTS
experimental, Counter
FROM RFC1155-SMI
PhysAddress
FROM RFC-1213
OBJECT-TYPE
FROM RFC-1212;
-- This MIB module uses the extended OBJECT-TYPE macro as
-- defined in [9]
-- the CLNS MIB module
clns OBJECT IDENTIFIER ::= { experimental 1 }
-- textual conventions
ClnpAddress ::=
OCTET STRING (SIZE (1..21))
-- This data type is used to model NSAP addresses.
-- groups in the CLNS MIB
clnp OBJECT IDENTIFIER ::= { clns 1 }
error OBJECT IDENTIFIER ::= { clns 2 }
echo OBJECT IDENTIFIER ::= { clns 3 }
es-is OBJECT IDENTIFIER ::= { clns 4 }
-- the CLNP group
-- Implementation of this group is recommended for all
-- systems which implement the CLNP.
Satz [Page 4]
RFC 1238 CLNS MIB June 1991
clnpForwarding OBJECT-TYPE
SYNTAX INTEGER {
is(1), -- entity is an intermediate system
-- entity is an end system and does
es(2) -- not forward PDUs
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The indication of whether this entity is active
as an intermediate or end system. Only
intermediate systems will forward PDUs onward that
are not addressed to them."
::= { clnp 1 }
clnpDefaultLifeTime OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The default value inserted into the Lifetime
field of the CLNP PDU header of PDUs sourced by
this entity."
::= { clnp 2 }
clnpInReceives OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of input PDUs received from all
connected network interfaces running CLNP,
including errors."
::= { clnp 3 }
clnpInHdrErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"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."
::= { clnp 4 }
Satz [Page 5]
RFC 1238 CLNS MIB June 1991
clnpInAddrErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"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."
::= { clnp 5 }
clnpForwPDUs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of input PDUs for which this entity
was not the final destination and which an attempt
was made to forward them onward."
::= { clnp 6 }
clnpInUnknownNLPs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"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)."
::= { clnp 7 }
clnpInUnknownULPs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of locally-addressed PDUs successfully
received but discarded because the upper layer
protocol was unknown or unsupported (e.g., not
TP4)."
::= { clnp 8 }
clnpInDiscards OBJECT-TYPE
SYNTAX Counter
Satz [Page 6]
RFC 1238 CLNS MIB June 1991
ACCESS read-only
STATUS mandatory
DESCRIPTION
"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."
::= { clnp 9 }
clnpInDelivers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of input PDUs successfully
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -