📄 rfc1238.txt
字号:
Network Working Group G. SatzRequest 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....................................... 321. 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 toSatz [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 CounterSatz [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 + -