From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1229.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc1229.txt (limited to 'doc/rfc/rfc1229.txt') diff --git a/doc/rfc/rfc1229.txt b/doc/rfc/rfc1229.txt new file mode 100644 index 0000000..f0025d3 --- /dev/null +++ b/doc/rfc/rfc1229.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group K. McCloghrie, Editor +Request for Comments: 1229 Hughes LAN Systems, Inc. + May 1991 + + + Extensions to the Generic-Interface MIB + +Status of this Memo + + This RFC contains definitions of managed objects used as experimental + extensions to the generic interfaces structure of MIB-II. This memo + is a product of the SNMP Working Group of the Internet Engineering + Task Force (IETF). This RFC specifies an IAB standards track + protocol for the Internet community, and requests discussion and + suggestions for improvements. 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. Abstract .............................................. 1 + 2. The Network Management Framework....................... 1 + 3. Objects ............................................... 2 + 4. Overview .............................................. 3 + 4.1 Generic Interface Extension Table .................... 3 + 4.2 Generic Interface Test Table ......................... 3 + 4.3 Generic Receive Address Table ........................ 4 + 5. Definitions ........................................... 5 + 6. Acknowledgements ...................................... 14 + 7. References ............................................ 15 + 8. Security Considerations................................ 15 + 9. Author's Address....................................... 16 + +1. Abstract + + This memo defines an experimental portion of the Management + Information Base (MIB) for use with network management protocols in + TCP/IP-based internets. In particular, it defines managed object + types as experimental extensions to the generic interfaces structure + of MIB-II. + +2. 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 + + + +SNMP Working Group [Page 1] + +RFC 1229 Interface MIB Extensions May 1991 + + + defines a more concise description mechanism, which is wholly + consistent with the SMI. + + 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. + +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. + + The SMI specifies the use of the basic encoding rules of ASN.1 [8], + subject to the additional requirements imposed by the SNMP. + + Section 5 contains the specification of all object types in this + section of the MIB. The object types are defined using the + conventions specified in the SMI, as amended by the extensions + specified in [9]. + + + + + + +SNMP Working Group [Page 2] + +RFC 1229 Interface MIB Extensions May 1991 + + +4. Overview + + The Internet Standard MIB [4,6] contains a group of management + objects pertaining to a network device's generic network + interface(s). These objects are generic in the sense that they apply + to all network interfaces, irrespective of the type of communication + media and protocols used on such interfaces. This has proved to be + necessary but not sufficient; there are efforts underway to define + additional MIB objects which are specific to particular media and + lower-level (subnetwork-layer and below) protocol stacks. + + However, some of these efforts have identified objects which are + required (or at least useful), but are not specific to the + interface-type on which the effort is focusing. In order to avoid + redundancy, it is better that such objects be defined as extensions + to the generic interface group, rather than defined in multiple + specific-interface-type MIBs. + + This memo defines the resultant extensions to the generic interface + group. These extensions are spread over three tables: the generic + Interface Extension table, the generic Interface Test table, and the + generic Receive Address table. + +4.1. Generic Interface Extension Table + + This table consists of new objects applicable to all types of + subnetwork interface. + +4.2. Generic Interface Test Table + + This section defines objects which allow a network manager to + instruct an agent to test an interface for various faults. A few + common types of tests are defined in this document but most will be + defined elsewhere, dependent on the particular type of interface. + After testing, the object ifExtnsTestResult can be read to determine + the outcome. If an agent cannot perform the test, ifExtnsTestResult + is set to so indicate. The object ifExtnsTestCode can be used to + provide further test-specific or interface-specific (or even + enterprise-specific) information concerning the outcome of the test. + Only one test can be in progress on each interface at any one time. + If one test is in progress when another test is invoked, the second + test is rejected. Some agents may reject a test when a prior test is + active on another interface. + + When a test is invoked, the identity of the originator of the request + and the request-id are saved by the agent in the objects + ifExtnsTestRequestId and ifExtnsTestCommunity. These values remain + set until the next test is invoked. In the (rare) event that the + + + +SNMP Working Group [Page 3] + +RFC 1229 Interface MIB Extensions May 1991 + + + invocation of tests by two network managers were to overlap, then + there would be a possibility that the first test's results might be + overwritten by the second test's results prior to the first results + being read. This unlikely circumstance can be detected by a network + manager retrieving ifExtnsTestCommunity, and ifExtnsTestRequestId at + the same time as the test results are retrieved, and ensuring that + the results are for the desired request. + + In general, a Management station must not retransmit a request to + invoke a test for which it does not receive a response; instead, it + properly inspects an agent's MIB to determine if the invocation was + successful. The invocation request is retransmitted only if the + invocation was unsuccessful. + + Some tests may require the interface to be taken off-line or may even + require the agent to be rebooted after completion of the test. In + these circumstances, communication with the management station + invoking the test may be lost until after completion of the test. + The agent should make every effort to transmit a response to the + request that invoked the test prior to losing communication. When + the agent is restored to normal service, the results of the test are + properly made available in the appropriate objects. Note that this + requires that the ifIndex value assigned to an interface must be + unchanged even if the test causes a reboot. An agent must reject any + test for which it cannot, perhaps due to resource constraints, make + available at least the minimum amount of information after that test + completes. + +4.3. Generic Receive Address Table + + This table contains objects relating to an interface's support for + receiving packets/frames at more than one address on the same + interface. + + + + + + + + + + + + + + + + + + +SNMP Working Group [Page 4] + +RFC 1229 Interface MIB Extensions May 1991 + + +5. Definitions + + + RFC1229-MIB DEFINITIONS ::= BEGIN + + + -- Extensions to MIB-II's Generic Interface Table + + IMPORTS + experimental, Counter FROM RFC1155-SMI + DisplayString, PhysAddress FROM RFC1213-MIB + OBJECT-TYPE FROM RFC-1212; + + + + ifExtensions OBJECT IDENTIFIER ::= { experimental 6 } + + + -- Generic Interface Extension Table + -- + -- This group of objects is mandatory for all types of + -- subnetwork interface. + + ifExtnsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IfExtnsEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "A list of interfaces extension entries. + The number of entries is given by the value + of ifNumber, defined in [4,6]." + ::= { ifExtensions 1 } + + ifExtnsEntry OBJECT-TYPE + SYNTAX IfExtnsEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "An extension to the interfaces entry, + defined in [4,6], containing additional + objects at the subnetwork layer and below + for a particular interface." + INDEX { ifExtnsIfIndex } + ::= { ifExtnsTable 1 } + + IfExtnsEntry ::= + SEQUENCE { + ifExtnsIfIndex + + + +SNMP Working Group [Page 5] + +RFC 1229 Interface MIB Extensions May 1991 + + + INTEGER, + ifExtnsChipSet + OBJECT IDENTIFIER, + ifExtnsRevWare + DisplayString, + ifExtnsMulticastsTransmittedOks + Counter, + ifExtnsBroadcastsTransmittedOks + Counter, + ifExtnsMulticastsReceivedOks + Counter, + ifExtnsBroadcastsReceivedOks + Counter, + ifExtnsPromiscuous + INTEGER + } + + ifExtnsIfIndex OBJECT-TYPE + SYNTAX INTEGER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The value of this object identifies the + interface for which this entry contains + extended management information. The value + of this object for a particular interface + has the same value as the ifIndex object, + defined in [4,6], for the same interface." + ::= { ifExtnsEntry 1 } + + ifExtnsChipSet OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This object identifies the hardware chip + set being used in the interface. The + assignment of OBJECT IDENTIFIERs to various + types of hardware chip sets is managed + by the IANA. If the hardware chip set is + unknown, the object identifier + + unknownChipSet OBJECT IDENTIFIER ::= { 0 0 } + + is returned. Note that unknownChipSet is a + syntactically valid object identifier, and + any conformant implementation of ASN.1 and + the BER must be able to generate and + + + +SNMP Working Group [Page 6] + +RFC 1229 Interface MIB Extensions May 1991 + + + recognize this value." + ::= { ifExtnsEntry 2 } + + ifExtnsRevWare OBJECT-TYPE + SYNTAX DisplayString (SIZE (0..255)) + ACCESS read-only + STATUS mandatory + DESCRIPTION + "An arbitrary octet string that describes + the firmware version of this interface. + It is intended that this should be human + readable. It must only contain ASCII + printable characters. Typically this + will be the firmware version of the main + interface software." + ::= { ifExtnsEntry 3 } + + ifExtnsMulticastsTransmittedOks OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The count of frames successfully + transmitted to a subnetwork or link-layer + multicast destination address other than a + broadcast address. For a MAC layer protocol, + this includes both Group and Functional + addresses." + ::= { ifExtnsEntry 4 } + + ifExtnsBroadcastsTransmittedOks OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The count of frames successfully + transmitted to a subnetwork or link-layer + broadcast addresses. It does not include + frames sent to a multicast address." + ::= { ifExtnsEntry 5 } + + ifExtnsMulticastsReceivedOks OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The count of frames successfully received + that are directed to an active subnetwork + + + +SNMP Working Group [Page 7] + +RFC 1229 Interface MIB Extensions May 1991 + + + or link-layer multicast address (for a MAC + layer protocol, this includes both Group and + Functional addresses). This does not include + frames directed to a broadcast address, nor + frames received with errors." + ::= { ifExtnsEntry 6 } + + ifExtnsBroadcastsReceivedOks OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The count of frames successfully received + that are directed to a subnetwork or + link-layer broadcast address. This does not + include frames received with errors." + ::= { ifExtnsEntry 7 } + + ifExtnsPromiscuous OBJECT-TYPE + SYNTAX INTEGER { + true(1), + false(2) + } + ACCESS read-only -- Note: agent implementors are + -- encouraged to extend this + -- access to read-write if that + -- makes sense in their agent. + STATUS mandatory + DESCRIPTION + "This object has a value of false(2) if + this interface only accepts packets/frames + that are addressed to this station. This + object has a value of true(1) when the + station accepts all packets/frames + transmitted on the media. The value + true(1) is only legal on certain types of + media. If legal, setting this object to a + value of true(1) may require the interface + to be reset before becoming effective." + ::= { ifExtnsEntry 8 } + + -- + -- Generic Interface Test Table + -- + -- This group of objects is optional, but if the table is + -- implemented, all objects in the table must be implemented. + + + + + +SNMP Working Group [Page 8] + +RFC 1229 Interface MIB Extensions May 1991 + + + ifExtnsTestTable OBJECT-TYPE + + SYNTAX SEQUENCE OF IfExtnsTestEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "This table contains one entry per interface." + ::= { ifExtensions 2 } + + ifExtnsTestEntry OBJECT-TYPE + SYNTAX IfExtnsTestEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "An entry containing objects for invoking + tests on an interface." + INDEX { ifExtnsTestIfIndex } + ::= { ifExtnsTestTable 1 } + + IfExtnsTestEntry ::= + SEQUENCE { + ifExtnsTestIfIndex + INTEGER, + ifExtnsTestCommunity + OCTET STRING, + ifExtnsTestRequestId + INTEGER, + ifExtnsTestType + OBJECT IDENTIFIER, + ifExtnsTestResult + INTEGER, + ifExtnsTestCode + OBJECT IDENTIFIER + } + + ifExtnsTestIfIndex OBJECT-TYPE + SYNTAX INTEGER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The value of this object identifies the + interface for which this entry contains + information on interface tests. The value + of this object for a particular interface + has the same value as the ifIndex object, + defined in [4,6], for the same interface." + ::= { ifExtnsTestEntry 1 } + + + + +SNMP Working Group [Page 9] + +RFC 1229 Interface MIB Extensions May 1991 + + + ifExtnsTestCommunity OBJECT-TYPE + SYNTAX OCTET STRING + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This object contains the name of the SNMP + authentication community [5] which was used + to authenticate the SNMP Message which invoked + the current or most recent test on this + interface. If the authentication community + is unknown or undefined, this value contains + the zero-length string." + ::= { ifExtnsTestEntry 2 } + + ifExtnsTestRequestId OBJECT-TYPE + SYNTAX INTEGER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This object contains the value of the + request-id field in the SNMP PDU [5] which + invoked the current or most recent test on + this interface. If the request-id is + unknown or undefined, this value contains + the value zero." + ::= { ifExtnsTestEntry 3 } + + ifExtnsTestType OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + ACCESS read-write + STATUS mandatory + DESCRIPTION + "A control variable used to start and stop + operator-initiated interface tests. + Most OBJECT IDENTIFIER values assigned + to tests are defined elsewhere, in associ- + ation with specific types of interface. + However, this document assigns a value for + a full-duplex loopback test, and defines the + special meanings of the subject identifier: + + noTest OBJECT IDENTIFIER ::= { 0 0 } + + When the value noTest is written to this + object, no action is taken unless a test is + in progress, in which case the test is + aborted. Writing any other value to this + object is only valid when no test is + + + +SNMP Working Group [Page 10] + +RFC 1229 Interface MIB Extensions May 1991 + + + currently in progress, in which case the + indicated test is initiated. + Note that noTest is a syntactically valid + object identifier, and any conformant + implementation of ASN.1 and BER must be able + to generate and recognize this value. + When read, this object always returns + the most recent value that ifExtnsTestType + was set to. If it has not been set since + the last initialization of the network + management subsystem on the agent, a value + of noTest is returned." + ::= { ifExtnsTestEntry 4 } + + wellKnownTests OBJECT IDENTIFIER ::= { ifExtensions 4 } + + -- full-duplex loopback test + testFullDuplexLoopBack OBJECT IDENTIFIER ::= + { wellKnownTests 1 } + + ifExtnsTestResult OBJECT-TYPE + SYNTAX INTEGER { + none(1), -- no test yet requested + success(2), + inProgress(3), + notSupported(4), + unAbleToRun(5), -- due to state of system + aborted(6), + failed(7) + } + ACCESS read-only + STATUS mandatory + DESCRIPTION + "This object contains the result of the most + recently requested test, or the value + none(1) if no tests have been requested since + the last reset. Note that this facility + provides no provision for saving the results + of one test when starting another, as could + be required if used by multiple managers + concurrently." + ::= { ifExtnsTestEntry 5 } + + ifExtnsTestCode OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + ACCESS read-only + STATUS mandatory + DESCRIPTION + + + +SNMP Working Group [Page 11] + +RFC 1229 Interface MIB Extensions May 1991 + + + "This object contains a code which contains + more specific information on the test result, + for example an error-code after a failed + test. Error codes and other values this + object may take are specific to the type of + interface and/or test. However, one subject + identifier: + + testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 } + + for use if no additional result code is + available. + Note that testCodeUnknown is a + syntactically valid object identifier, and + any conformant implementation of ASN.1 and + the BER must be able to generate and + recognize this value." + ::= { ifExtnsTestEntry 6 } + + + -- Generic Receive Address Table + -- + -- This group of objects is mandatory for all types of + -- interfaces which can receive packets/frames addressed to + -- more than one address. + + ifExtnsRcvAddrTable OBJECT-TYPE + SYNTAX SEQUENCE OF IfExtnsRcvAddrEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "This table contains an entry for each + address (broadcast, multicast, or uni-cast) + for which the system will receive packets/ + frames on a particular interface. When an + interface is operating in promiscuous mode, + entries are only required for those addresses + for which the system would receive frames + were it not operating in promiscuous mode." + ::= { ifExtensions 3 } + + ifExtnsRcvAddrEntry OBJECT-TYPE + SYNTAX IfExtnsRcvAddrEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "A list of objects identifying an address + for which the system will accept packets/ + + + +SNMP Working Group [Page 12] + +RFC 1229 Interface MIB Extensions May 1991 + + + frames on a particular interface." + INDEX { ifExtnsRcvAddrIfIndex, ifExtnsRcvAddress } + ::= { ifExtnsRcvAddrTable 1 } + + IfExtnsRcvAddrEntry ::= + SEQUENCE { + ifExtnsRcvAddrIfIndex + INTEGER, + ifExtnsRcvAddress + PhysAddress, + ifExtnsRcvAddrStatus + INTEGER + } + + ifExtnsRcvAddrIfIndex OBJECT-TYPE + SYNTAX INTEGER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The value of ifIndex, defined in [4,6], of an + interface which recognizes this entry's + address." + ::= { ifExtnsRcvAddrEntry 1 } + + ifExtnsRcvAddress OBJECT-TYPE + SYNTAX PhysAddress + ACCESS read-only + STATUS mandatory + DESCRIPTION + "An address for which the system will accept + packets/frames on this entry's interface." + ::= { ifExtnsRcvAddrEntry 2 } + + ifExtnsRcvAddrStatus OBJECT-TYPE + SYNTAX INTEGER { + other(1), + invalid(2), + volatile(3), + nonVolatile(4) + } + ACCESS read-write + STATUS mandatory + DESCRIPTION + "This object has the value nonVolatile(4) + for those entries in the table which are + valid and will not be deleted by the next + restart of the managed system. Entries + having the value volatile(3) are valid + + + +SNMP Working Group [Page 13] + +RFC 1229 Interface MIB Extensions May 1991 + + + and exist, but have not been saved, so + that will not exist after the next + restart of the managed system. Entries + having the value other(1) are valid and + exist but are not classified as to whether + they will continue to exist after the next + restart. Entries having the value invalid(2) + are invalid and do not represent an address + for which an interface accepts frames. + Setting an object instance to one of + the values other(1), volatile(3), or + nonVolatile(4) causes the corresponding + entry to exist or continue to exist, and + to take on the respective status as regards + the next restart of the managed system. + Setting an object instance to the value + invalid(2) causes the corresponding entry + to become invalid or cease to exist. + It is an implementation-specific matter + as to whether the agent removes an + invalidated entry from the table. + Accordingly, management stations must be + prepared to receive tabular information + from agents that corresponds to entries not + currently in use. Proper interpretation of + such entries requires examination of the + relevant ifExtnsRcvAddrStatus object + instance." + DEFVAL { volatile } + ::= { ifExtnsRcvAddrEntry 3 } + + END + +6. Acknowledgements + + Most of the MIB objects defined in this document were originally + proposed as a part of a MIB for management of IEEE 802.5 Token Ring + networks, as prepared by: + + Eric B. Decker, cisco Systems, Inc., and + Richard Fox, Synoptics Inc. + + In addition, the comments of the following individuals are + acknowledged: + + James R. Davin, MIT-LCS + Stan Froyd, ACC + Frank Kastenholz, Racal Interlan + + + +SNMP Working Group [Page 14] + +RFC 1229 Interface MIB Extensions May 1991 + + + Dave Perkins, 3Com + Marshall T. Rose, PSI + Bob Stewart, Xyplex + David Waitzman, BBN + Wengyik Yeong, PSI + +7. References + + [1] Cerf, V., "IAB Recommendations for the Development of Internet + Network Management Standards", RFC 1052, NRI, April 1988. + + [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review + Group", RFC 1109, NRI, August 1989. + + [3] Rose M., and K. McCloghrie, "Structure and Identification of + Management Information for TCP/IP-based internets", RFC 1155, + Performance Systems International, Hughes LAN Systems, May 1990. + + [4] McCloghrie K., and M. Rose, "Management Information Base for + Network Management of TCP/IP-based internets", RFC 1156, Hughes + LAN Systems, Performance Systems International, May 1990. + + [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple + Network Management Protocol", RFC 1157, SNMP Research, + Performance Systems International, Performance Systems + International, MIT Laboratory for Computer Science, May 1990. + + [6] Rose M., Editor, "Management Information Base for Network + Management of TCP/IP-based internets: MIB-II", RFC 1213, + Performance Systems International, March 1991. + + [7] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization, International + Standard 8824, December 1987. + + [8] Information processing systems - Open Systems Interconnection - + Specification of Basic Encoding Rules for Abstract Notation One + (ASN.1), International Organization for Standardization, + International Standard 8825, December 1987. + + [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", + RFC 1212, Performance Systems International, Hughes LAN Systems, + March 1991. + +8. Security Considerations + + Security issues are not discussed in this memo. + + + +SNMP Working Group [Page 15] + +RFC 1229 Interface MIB Extensions May 1991 + + +9. Author's Address + + Keith McCloghrie + Hughes LAN Systems, Inc. + 1225 Charleston Road + Mountain View, CA 94043 + + Phone: (415) 966-7934 + + EMail: kzm@hls.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +SNMP Working Group [Page 16] + \ No newline at end of file -- cgit v1.2.3