summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1284.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1284.txt')
-rw-r--r--doc/rfc/rfc1284.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc1284.txt b/doc/rfc/rfc1284.txt
new file mode 100644
index 0000000..ff267e8
--- /dev/null
+++ b/doc/rfc/rfc1284.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group J. Cook, Editor
+Request for Comments: 1284 Chipcom Corporation
+ December 1991
+
+
+ Definitions of Managed Objects
+ for the Ethernet-like Interface Types
+
+Status 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.......................................... 21
+
+1. 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 1212
+
+
+
+Transmission 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 1991
+
+
+4. 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 1991
+
+
+5. 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
+
+
+
+Transmission MIB Working Group [Page 7]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ STATUS mandatory
+ DESCRIPTION
+ "The transmit layer management state variable
+ (transmitEnabled as defined in [9]) for a
+ particular interface. The value true(1) signifies
+ that the MAC frame transmission is enabled on said
+ interface. The value false(2) signifies that the
+ MAC frame transmission is inhibited on said
+ interface. In particular, the value of an instance
+ of this object is false(2) whenever the value of
+ the corresponding instance of the
+ dot3MacSubLayerStatus object is disabled(2).
+
+ Each alteration of an instance of this object to
+ the value true(1) is analogous to an invocation of
+ the enableTransmit action defined in [9] and has
+ the effect of enabling MAC sublayer frame
+ transmission on the associated interface. In
+ particular, such an alteration has the effect of
+ setting the transmit layer management state
+ variable (transmitEnabled in [9]) for said
+ interface to be true.
+
+ Each alteration of an instance of this object to
+ the value false(2) is analogous to an invocation
+ of the disableTransmit action defined in [9] and
+ has the effect of inhibiting MAC sublayer frame
+ transmission on the associated interface. In
+ particular, such an alteration has the effect of
+ setting the transmit layer management state
+ variable (transmitEnabled in [9]) for said
+ interface to be false. Any transmissions in
+ progress are completed before transmission is
+ inhibited."
+ ::= { dot3Entry 5 }
+
+ dot3TestTdrValue OBJECT-TYPE
+ SYNTAX Gauge
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of 10 MHz ticks which elapsed between
+ the beginning of a TDR measurement and the
+ collision which ended it, for the most recently
+ executed TDR test. If no TDR test has been
+ executed, or the last TDR value is not available,
+ this object has the value 0."
+ ::= { dot3Entry 6 }
+
+
+
+Transmission MIB Working Group [Page 8]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ -- the Ethernet-like Statistics group
+
+ -- Implementation of this group is mandatory
+
+ -- Due to implementation restrictions (e.g. in the
+ -- instrumentation provided by a chipset, or a device
+ -- driver), some of the counters in this group may be
+ -- difficult or impossible to implement.
+ -- In such cases, an implementator should apply reasonable
+ -- best effort to detect as many occurrences as possible.
+ -- In any case, the value of a counter will be the number
+ -- actually detected, which will always be less or equal
+ -- to the number of actual occurrences. In the extreme
+ -- case of a total inability to detect occurrences, the
+ -- counter will always be zero.
+
+ -- Vendors are strongly encouraged to document in user guides and
+ -- other appropriate documentation the conditions under which the
+ -- values of the counters in this group may represent an
+ -- underestimate of the true count.
+
+ dot3StatsTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot3StatsEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "Statistics for a collection of ethernet-like
+ interfaces attached to a particular system."
+ ::= { dot3 2 }
+
+ dot3StatsEntry OBJECT-TYPE
+ SYNTAX Dot3StatsEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "Statistics for a particular interface to an
+ ethernet-like medium."
+ INDEX { dot3StatsIndex }
+ ::= { dot3StatsTable 1 }
+
+ Dot3StatsEntry ::=
+ SEQUENCE {
+ dot3StatsIndex
+ INTEGER,
+ dot3StatsAlignmentErrors
+ Counter,
+ dot3StatsFCSErrors
+ Counter,
+
+
+
+Transmission MIB Working Group [Page 9]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ dot3StatsSingleCollisionFrames
+ Counter,
+ dot3StatsMultipleCollisionFrames
+ Counter,
+ dot3StatsSQETestErrors
+ Counter,
+ dot3StatsDeferredTransmissions
+ Counter,
+ dot3StatsLateCollisions
+ Counter,
+ dot3StatsExcessiveCollisions
+ Counter,
+ dot3StatsInternalMacTransmitErrors
+ Counter,
+ dot3StatsCarrierSenseErrors
+ Counter,
+ dot3StatsExcessiveDeferrals
+ Counter,
+ dot3StatsFrameTooLongs
+ Counter,
+ dot3StatsInRangeLengthErrors
+ Counter,
+ dot3StatsOutOfRangeLengthFields
+ Counter,
+ dot3StatsInternalMacReceiveErrors
+ Counter
+ }
+
+ dot3StatsIndex 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."
+ ::= { dot3StatsEntry 1 }
+
+ dot3StatsAlignmentErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of frames received on a particular
+ interface that are not an integral number of
+ octets in length and do not pass the FCS check.
+
+
+
+Transmission MIB Working Group [Page 10]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ The count represented by an instance of this
+ object is incremented when the alignmentError
+ status is returned by the MAC service to the LLC
+ (or other MAC user). Received frames for which
+ multiple error conditions obtain are, according to
+ the conventions of [9], counted exclusively
+ according to the error status presented to the
+ LLC."
+ ::= { dot3StatsEntry 2 }
+
+ dot3StatsFCSErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of frames received on a particular
+ interface that are an integral number of octets in
+ length but do not pass the FCS check.
+
+ The count represented by an instance of this
+ object is incremented when the frameCheckError
+ status is returned by the MAC service to the LLC
+ (or other MAC user). Received frames for which
+ multiple error conditions obtain are, according to
+ the conventions of [9], counted exclusively
+ according to the error status presented to the
+ LLC."
+ ::= { dot3StatsEntry 3 }
+
+ dot3StatsSingleCollisionFrames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of successfully transmitted frames on a
+ particular interface for which transmission is
+ inhibited by exactly one collision.
+
+ A frame that is counted by an instance of this
+ object is also counted by the corresponding
+ instance of either the ifOutUcastPkts or
+ ifOutNUcastPkts object and is not counted by the
+ corresponding instance of the
+ dot3StatsMultipleCollisionFrames object."
+ ::= { dot3StatsEntry 4 }
+
+
+
+
+
+
+Transmission MIB Working Group [Page 11]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ dot3StatsMultipleCollisionFrames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of successfully transmitted frames on a
+ particular interface for which transmission is
+ inhibited by more than one collision.
+
+ A frame that is counted by an instance of this
+ object is also counted by the corresponding
+ instance of either the ifOutUcastPkts or
+ ifOutNUcastPkts object and is not counted by the
+ corresponding instance of the
+ dot3StatsSingleCollisionFrames object."
+ ::= { dot3StatsEntry 5 }
+
+ dot3StatsSQETestErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of times that the SQE TEST ERROR message
+ is generated by the PLS sublayer for a particular
+ interface. The SQE TEST ERROR message is defined
+ in section 7.2.2.2.4 of [12] and its generation is
+ described in section 7.2.4.6 of the same
+ document."
+ ::= { dot3StatsEntry 6 }
+
+ dot3StatsDeferredTransmissions OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of frames for which the first
+ transmission attempt on a particular interface is
+ delayed because the medium is busy.
+
+ The count represented by an instance of this
+ object does not include frames involved in
+ collisions."
+ ::= { dot3StatsEntry 7 }
+
+ dot3StatsLateCollisions OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+
+
+
+Transmission MIB Working Group [Page 12]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ DESCRIPTION
+ "The number of times that a collision is detected
+ on a particular interface later than 512 bit-times
+ into the transmission of a packet.
+
+ Five hundred and twelve bit-times corresponds to
+ 51.2 microseconds on a 10 Mbit/s system. A (late)
+ collision included in a count represented by an
+ instance of this object is also considered as a
+ (generic) collision for purposes of other
+ collision-related statistics."
+ ::= { dot3StatsEntry 8 }
+
+ dot3StatsExcessiveCollisions OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of frames for which transmission on a
+ particular interface fails due to excessive
+ collisions."
+ ::= { dot3StatsEntry 9 }
+
+ dot3StatsInternalMacTransmitErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of frames for which transmission on a
+ particular interface fails due to an internal MAC
+ sublayer transmit error. A frame is only counted
+ by an instance of this object if it is not counted
+ by the corresponding instance of either the
+ dot3StatsLateCollisions object, the
+ dot3StatsExcessiveCollisions object, the
+ dot3StatsCarrierSenseErrors object, or the
+ dot3StatsExcessiveDeferrals object.
+
+ The precise meaning of the count represented by an
+ instance of this object is implementation-
+ specific. In particular, an instance of this
+ object may represent a count of transmission
+ errors on a particular interface that are not
+ otherwise counted."
+ ::= { dot3StatsEntry 10 }
+
+
+
+
+
+
+Transmission MIB Working Group [Page 13]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ dot3StatsCarrierSenseErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of times that the carrier sense
+ condition was lost or never asserted when
+ attempting to transmit a frame on a particular
+ interface.
+
+ The count represented by an instance of this
+ object is incremented at most once per
+ transmission attempt, even if the carrier sense
+ condition fluctuates during a transmission
+ attempt."
+ ::= { dot3StatsEntry 11 }
+
+ dot3StatsExcessiveDeferrals OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of frames for which transmission on a
+ particular interface is deferred for an excessive
+ period of time."
+ ::= { dot3StatsEntry 12 }
+
+ dot3StatsFrameTooLongs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of frames received on a particular
+ interface that exceed the maximum permitted frame
+ size.
+
+ The count represented by an instance of this
+ object is incremented when the frameTooLong status
+ is returned by the MAC service to the LLC (or
+ other MAC user). Received frames for which
+ multiple error conditions obtain are, according to
+ the conventions of [9], counted exclusively
+ according to the error status presented to the
+ LLC."
+ ::= { dot3StatsEntry 13 }
+
+
+
+
+
+
+Transmission MIB Working Group [Page 14]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ dot3StatsInRangeLengthErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of frames received on a particular
+ interface with a length field value that falls
+ between the minimum unpadded LLC data size and the
+ maximum allowed LLC data size inclusive and that
+ does not match the number of LLC data octets
+ received.
+
+ The count represented by an instance of this
+ object also includes frames for which the length
+ field value is less than the minimum unpadded LLC
+ data size."
+ ::= { dot3StatsEntry 14 }
+
+ dot3StatsOutOfRangeLengthFields OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of frames received on a particular
+ interface for which the length field value exceeds
+ the maximum allowed LLC data size.
+
+ The count represented by an instance of this
+ object is not incremented in implementations that
+ observe Ethernet encapsulation conventions (by
+ which the IEEE 802.3 length field is interpreted
+ as the Ethernet Type field)."
+ ::= { dot3StatsEntry 15 }
+
+ dot3StatsInternalMacReceiveErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of frames for which reception on a
+ particular interface fails due to an internal MAC
+ sublayer receive error. A frame is only counted by
+ an instance of this object if it is not counted by
+ the corresponding instance of either the
+ dot3StatsFrameTooLongs object, the
+ dot3StatsAlignmentErrors object, the
+ dot3StatsFCSErrors object, the
+ dot3StatsInRangeLengthErrors object, or the
+
+
+
+Transmission MIB Working Group [Page 15]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ dot3StatsOutOfRangeLengthFields object.
+
+ The precise meaning of the count represented by an
+ instance of this object is implementation-
+ specific. In particular, an instance of this
+ object may represent a count of receive errors on
+ a particular interface that are not otherwise
+ counted."
+ ::= { dot3StatsEntry 16 }
+
+
+ -- the Ethernet-like Collision Statistics group
+
+ -- Implementation of this group is optional; it is appropriate
+ -- for all systems which have the necessary metering
+
+ dot3CollTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot3CollEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "A collection of collision histograms for a
+ particular set of interfaces."
+ ::= { dot3 5 }
+
+ dot3CollEntry OBJECT-TYPE
+ SYNTAX Dot3CollEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "A cell in the histogram of per-frame collisions
+ for a particular interface. An instance of this
+ object represents the frequency of individual MAC
+ frames for which the transmission (successful or
+ otherwise) on a particular interface is
+ accompanied by a particular number of media
+ collisions."
+ INDEX { dot3CollIndex, dot3CollCount }
+ ::= { dot3CollTable 1 }
+
+ Dot3CollEntry ::=
+ SEQUENCE {
+ dot3CollIndex
+ INTEGER,
+ dot3CollCount
+ INTEGER,
+ dot3CollFrequencies
+ Counter
+
+
+
+Transmission MIB Working Group [Page 16]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ }
+
+ dot3CollIndex OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The index value that uniquely identifies the
+ interface to which a particular collision
+ histogram cell pertains. The interface identified
+ by a particular value of this index is the same
+ interface as identified by the same value of
+ ifIndex."
+ ::= { dot3CollEntry 1 }
+
+ dot3CollCount OBJECT-TYPE
+ SYNTAX INTEGER (1..16)
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of per-frame media collisions for
+ which a particular collision histogram cell
+ represents the frequency on a particular
+ interface."
+ ::= { dot3CollEntry 2 }
+
+ dot3CollFrequencies OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "A count of individual MAC frames for which the
+ transmission (successful or otherwise) on a
+ particular interface is accompanied by a
+ particular number of media collisions."
+ ::= { dot3CollEntry 3 }
+
+
+ -- 802.3 Tests
+
+ -- The ifExtnsTestTable defined in [11] provides a common means
+ -- for a manager to test any interface corresponding to a value
+ -- of ifIndex.
+
+ -- At this time, one well known test (testFullDuplexLoopBack) is
+ -- defined in [11]. For ethernet-like interfaces, this test
+ -- configures the MAC chip and executes an internal loopback
+ -- test of memory and the MAC chip logic. This loopback test can
+
+
+
+Transmission MIB Working Group [Page 17]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ -- only be executed if the interface is offline. Once the test
+ -- has completed, the MAC chip should be reinitialized for network
+ -- operation, but it should remain offline.
+
+ -- If an error occurs during a test, the object ifExtnsTestResult
+ -- (defined in [11]) will be set to failed(7). The following two
+ -- OBJECT IDENTIFIERs may be used to provided more information as
+ -- values for the object ifExtnsTestCode in [11]:
+
+ dot3Errors OBJECT IDENTIFIER ::= { dot3 7 }
+
+ -- couldn't initialize MAC chip for test
+ dot3ErrorInitError OBJECT IDENTIFIER ::= { dot3Errors 1 }
+
+ -- expected data not received (or not
+ -- received correctly) in loopback test
+ dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 }
+
+
+ -- TDR Test
+
+ -- Another test, specific to ethernet-like interfaces,
+ -- is Time-domain Reflectometry (TDR) which is defined
+ -- as follows:
+
+ dot3Tests OBJECT IDENTIFIER ::= { dot3 6 }
+ dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 }
+
+ -- A TDR test returns as its result the time interval between the
+ -- most recent TDR test transmission and the subsequent detection
+ -- of a collision. This interval is based on a 10 MHz clock and
+ -- should be normalized if the time base is other than 10 MHz.
+ -- On successful completion of a TDR test, the result is stored
+ -- as the value of the appropriate instance of the MIB object
+ -- dot3TestTdrValue, and the OBJECT IDENTIFIER of that instance
+ -- is stored in the corresponding instance of ifExtnsTestResult
+ -- (thereby indicating where the result has been stored).
+
+
+ -- 802.3 Hardware Chipsets
+
+ -- The object ifExtnsChipSet is provided in [11] to identify the
+ -- MAC hardware used to communcate on an interface. The following
+ -- hardware chipsets are provided for 802.3:
+
+ dot3ChipSets OBJECT IDENTIFIER ::= { dot3 8 }
+ dot3ChipSetAMD OBJECT IDENTIFIER ::= { dot3ChipSets 1 }
+ dot3ChipSetAMD7990 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 1 }
+
+
+
+Transmission MIB Working Group [Page 18]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ dot3ChipSetAMD79900 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 2 }
+
+ dot3ChipSetIntel OBJECT IDENTIFIER ::= { dot3ChipSets 2 }
+ dot3ChipSetIntel82586 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 1 }
+ dot3ChipSetIntel82596 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 2 }
+
+ dot3ChipSetSeeq OBJECT IDENTIFIER ::= { dot3ChipSets 3 }
+ dot3ChipSetSeeq8003 OBJECT IDENTIFIER ::= { dot3ChipSetSeeq 1 }
+
+ dot3ChipSetNational OBJECT IDENTIFIER ::= { dot3ChipSets 4 }
+ dot3ChipSetNational8390 OBJECT IDENTIFIER ::=
+ { dot3ChipSetNational 1 }
+ dot3ChipSetNationalSonic OBJECT IDENTIFIER ::=
+ { dot3ChipSetNational 2 }
+
+ dot3ChipSetFujitsu OBJECT IDENTIFIER ::= { dot3ChipSets 5 }
+ dot3ChipSetFujitsu86950 OBJECT IDENTIFIER ::=
+ { dot3ChipSetFujitsu 1 }
+
+ -- For those chipsets not represented above, OBJECT IDENTIFIER
+ -- assignment is required in other documentation, e.g., assignment
+ -- within that part of the registration tree delegated to
+ -- individual enterprises (see [3]).
+
+ END
+
+6. Acknowledgements
+
+ This document was produced by the Transmission MIB Working Group.
+
+ This document is based on a document written by Frank Kastenholz of
+ Interlan entitled IEEE 802.3 Layer Management Draft M compatible MIB
+ for TCP/IP Networks [10]. This document has been modestly reworked,
+ initially by the SNMP Working Group, and then by the Transmission
+ Working Group, to reflect the current conventions for defining
+ objects for MIB interfaces. James Davin, of the MIT Laboratory for
+ Computer Science, and Keith McCloghrie of Hughes LAN Systems,
+ contributed to later drafts of this memo. Marshall Rose of
+ Performance Systems International, Inc. converted the document into
+ its current concise format. Thanks to Frank Kastenholz of Interlan
+ and Louis Steinberg of IBM for their experimentation.
+
+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
+
+
+
+Transmission MIB Working Group [Page 19]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+ 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] McCloghrie K., and M. Rose, Editors, "Management Information Base
+ for Network Management of TCP/IP-based internets", 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] IEEE, "IEEE 802.3 Layer Management", November 1988.
+
+ [10] Kastenholz, F., IEEE 802.3 Layer Management Draft compatible MIB
+ for TCP/IP Networks, electronic mail message to mib-
+ wg@nnsc.nsf.net, 9 June 1989.
+
+ [11] McCloghrie, K., Editor, "Extensions to the Generic-Interface
+ MIB", RFC 1229, Hughes LAN Systems, Inc., May 1991.
+
+ [12] IEEE, "Carrier Sense Multiple Access with Collision Detection
+ (CSMA/CD) Access Method and Physical Layer Specifications",
+ ANSI/IEEE Std 802.3-1985.
+
+ [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+ RFC 1212, Performance Systems International, Hughes LAN Systems,
+ March 1991.
+
+
+
+
+
+
+Transmission MIB Working Group [Page 20]
+
+RFC 1284 ETHERNET-LIKE OBJECTS December 1991
+
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address
+
+ John Cook
+ Chipcom Corporation
+ 118 Turnpike Road
+ Southborough, MA 01772
+
+ For more information, contact the chair of the Ethernet MIB working
+ group:
+
+ Frank Kastenholz
+ Clearpoint Research Inc
+ 35 Parkwood Drive
+ Hopkinton Mass 01748
+
+ Phone: 508-435-2000
+ EMail: kasten@europa.clearpoint.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Transmission MIB Working Group [Page 21]
+ \ No newline at end of file