📄 rfc1229.txt
字号:
Network Working Group K. McCloghrie, EditorRequest for Comments: 1229 Hughes LAN Systems, Inc. May 1991 Extensions to the Generic-Interface MIBStatus 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....................................... 161. 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 1212SNMP 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 19914. 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 theSNMP 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 19915. 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 { ifExtnsIfIndexSNMP 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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -