?? rfc1284.txt
字號:
Network Working Group J. Cook, EditorRequest for Comments: 1284 Chipcom Corporation December 1991 Definitions of Managed Objects for the Ethernet-like Interface TypesStatus of this Memo This memo is an extension to the SNMP MIB. 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 3.1 Format of Definitions ................................ 2 4. Overview .............................................. 3 5. Definitions ........................................... 4 5.1 The Generic Ethernet-like Group ...................... 4 5.2 The Ethernet-Like Statistics Group ................... 9 5.3 The Ethernet-like Collision Statistics Group ......... 16 5.4 802.3 Tests .......................................... 17 5.5 802.3 Hardware Chipsets .............................. 18 6. Acknowledgements ...................................... 19 7. References ............................................ 19 Security Considerations................................... 21 Author's Address.......................................... 211. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ethernet-like objects.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 1212Transmission MIB Working Group [Page 1]RFC 1284 ETHERNET-LIKE OBJECTS December 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.3.1. Format of Definitions Section 5 contains 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 [13].Transmission MIB Working Group [Page 2]RFC 1284 ETHERNET-LIKE OBJECTS December 19914. Overview Instances of these object types represent attributes of an interface to an ethernet-like communications medium. At present, ethernet-like media are identified by three values of the ifType object in the Internet-standard MIB: ethernet-csmacd(6) iso88023-csmacd(7) starLan(11) For these interfaces, the value of the ifSpecific variable in the MIB-II [6] has the OBJECT IDENTIFIER value: dot3 OBJECT IDENTIFER ::= { transmission 7 } The definitions presented here are based on the IEEE 802.3 Layer Management Specification [9], as originally interpreted by Frank Kastenholz of Interlan in [10]. Implementors of these MIB objects should note that the IEEE document explicitly describes (in the form of Pascal pseudocode) when, where, and how various MAC attributes are measured. The IEEE document also describes the effects of MAC actions that may be invoked by manipulating instances of the MIB objects defined here. To the extent that some of the attributes defined in [9] are represented by previously defined objects in the Internet-standard MIB or in the generic interface extensions MIB [11], such attributes are not redundantly represented by objects defined in this memo. Among the attributes represented by objects defined in other memos are the number of octets transmitted or received on a particular interface, the number of frames transmitted or received on a particular interface, the promiscuous status of an interface, the MAC address of an interface, and multicast information associated with an interface. The relationship between an ethernet-like interface and an interface in the context of the Internet-standard MIB is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein.Transmission MIB Working Group [Page 3]RFC 1284 ETHERNET-LIKE OBJECTS December 19915. Definitions RFC1284-MIB DEFINITIONS ::= BEGIN IMPORTS Counter, Gauge FROM RFC1155-SMI transmission FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [13] -- this is the MIB module for ethernet-like objects dot3 OBJECT IDENTIFIER ::= { transmission 7 } -- the Generic Ethernet-like group -- Implementation of this group is mandatory for all systems -- that attach to an ethernet-like medium. dot3Table OBJECT-TYPE SYNTAX SEQUENCE OF Dot3Entry ACCESS not-accessible STATUS mandatory DESCRIPTION "Status information and control variables for a collection of ethernet-like interfaces attached to a particular system." ::= { dot3 1 } dot3Entry OBJECT-TYPE SYNTAX Dot3Entry ACCESS not-accessible STATUS mandatory DESCRIPTION "Status information and control variables for a particular interface to an ethernet-like medium." INDEX { dot3Index } ::= { dot3Table 1 }Transmission MIB Working Group [Page 4]RFC 1284 ETHERNET-LIKE OBJECTS December 1991 Dot3Entry ::= SEQUENCE { dot3Index INTEGER, dot3InitializeMac INTEGER, dot3MacSubLayerStatus INTEGER, dot3MulticastReceiveStatus INTEGER, dot3TxEnabled INTEGER, dot3TestTdrValue Gauge } dot3Index OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "An index value that uniquely identifies an interface to an ethernet-like medium. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." ::= { dot3Entry 1 } dot3InitializeMac OBJECT-TYPE SYNTAX INTEGER { initialized(1), uninitialized(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The initialization status of the MAC and PLS (Physical Layer Signalling) subsystems for a particular interface. The value initialized(1) signifies that the subsystems for a particular interface have been previously initialized; the value uninitialized(2) signifies that they have not been previously initialized. Each alteration of an instance of this object to either of the values initialized(1) or uninitialized(2) is analogous to an invocation of the initializeMAC action defined in [9] and has the effect of (re-)initializing the MAC and PLS subsystems for the associated interface. In particular,Transmission MIB Working Group [Page 5]RFC 1284 ETHERNET-LIKE OBJECTS December 1991 all management counters pertaining to the MAC and PLS subsystems for said interface are reset to zero; the receive and transmit layer management state variables (receiveEnabled and transmitEnabled in [9]) are set to enable reception and transmission of frames; the promiscuous receive function is disabled; and multicast reception is disabled." ::= { dot3Entry 2 } dot3MacSubLayerStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The operational status of the MAC sublayer for a particular interface. The value enabled(1) signifies that the MAC sublayer for said interface is operational for both transmitting and receiving frames -- that is, that the value of both the receive and transmit layer management state variables (receiveEnabled and transmitEnabled in [9]) for said interface are true. The value disabled(2) signifies that the MAC sublayer for said interface is not operational for either transmitting or receiving frames. In particular, the value of an instance of this object is disabled(2) whenever the value of the corresponding instance of the dot3Enabled object is false(2). Each alteration of an instance of this object to the value enabled(1) is analogous to an invocation of the enableMACSublayer action defined in [9] and has the effect of starting normal transmit and receive operations (from the ``idle'' state) on the associated interface. In particular, such an alteration has the effect of resetting the PLS for said interface and of setting the receive and transmit layer management state variables (receiveEnabled and transmitEnabled in [9]) to be true.Transmission MIB Working Group [Page 6]RFC 1284 ETHERNET-LIKE OBJECTS December 1991 Each alteration of an instance of this object to the value disabled(2) is analogous to an invocation of the disableMACSublayer action defined in [9] and has the effect of terminating transmit and receive operations on the associated interface. In particular, such an alteration has the effect of setting the receive and transmit layer management state variables (receiveEnabled and transmitEnabled in [9]) to be false. Any transmissions/receptions in progress are completed before operation is terminated." ::= { dot3Entry 3 } dot3MulticastReceiveStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The multicast receive status for a particular interface. The value enabled(1) signifies that reception of multicast frames by the MAC sublayer is enabled on said interface. The value disabled(2) signifies that reception of multicast frames by the MAC sublayer is not enabled on said interface. Each alteration of an instance of this object to the value enabled(1) is analogous to an invocation of the enableMulticastReceive action defined in [9] and has the effect of enabling multicast frame reception on the associated interface. Actual reception of multicast frames is only possible on an interface when the values for the associated instances of the dot3MulticastReceiveStatus and dot3MacSubLayerStatus objects are enabled(1) and enabled(1), respectively. Each alteration of an instance of this object to the value disabled(2) is analogous to an invocation of the disableMulticastReceive action defined in [9] and has the effect of inhibiting multicast frame reception on the associated interface." ::= { dot3Entry 4 } dot3TxEnabled OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-write
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -