home *** CD-ROM | disk | FTP | other *** search
/ A Beginner's Guide to the Internet / INTERNET.ISO / text / std / std0050.txt < prev    next >
Encoding:
Text File  |  1995-04-05  |  37.8 KB  |  1,068 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      F. Kastenholz
  8. Request for Comments: 1623                            FTP Software, Inc.
  9. Obsoletes: 1398                                                 May 1994
  10. STD: 50
  11. Category: Standards Track
  12.  
  13.  
  14.                    Definitions of Managed Objects for
  15.                    the Ethernet-like Interface Types
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet standards track protocol for the
  20.    Internet community, and requests discussion and suggestions for
  21.    improvements.  Please refer to the current edition of the "Internet
  22.    Official Protocol Standards" (STD 1) for the standardization state
  23.    and status of this protocol.  Distribution of this memo is unlimited.
  24.  
  25. Table of Contents
  26.  
  27.    Introduction .............................................    1
  28.    1. The SNMP Network Management Framework .................    2
  29.    1.1 Object Definitions ...................................    2
  30.    2. Change Log ............................................    2
  31.    3. Overview ..............................................    3
  32.    3.1 Relation to RFC 1213 .................................    4
  33.    3.2 Relation to RFC 1573 .................................    4
  34.    3.2.1 Layering Model .....................................    4
  35.    3.2.2 Virtual Circuits ...................................    4
  36.    3.2.3 ifTestTable ........................................    4
  37.    3.2.4 ifRcvAddressTable ..................................    5
  38.    3.2.5 ifPhysAddress ......................................    5
  39.    3.2.6 ifType .............................................    6
  40.    4. Definitions ...........................................    6
  41.    5. Acknowledgements ......................................   16
  42.    6. References ............................................   17
  43.    7. Security Considerations ...............................   19
  44.    8. Author's Address ......................................   19
  45.  
  46. Introduction
  47.  
  48.    This memo defines a portion of the Management Information Base (MIB)
  49.    for use with network management protocols in the Internet community.
  50.    In particular, it defines objects for managing ethernet-like objects.
  51.  
  52.    This memo also includes a MIB module.  This MIB module corrects minor
  53.    errors in the earlier version of this MIB: RFC 1398 [15].
  54.  
  55.  
  56.  
  57.  
  58. Kastenholz                                                      [Page 1]
  59.  
  60. RFC 1623                   Ethernet-Like MIB                    May 1994
  61.  
  62.  
  63. 1.  The SNMP Network Management Framework
  64.  
  65.    The SNMP Network Management Framework consists of three major
  66.    components.  They are:
  67.  
  68.       o    STD 16/RFC 1155 [3] which defines the SMI, the mechanisms
  69.            used for describing and naming objects for the purpose of
  70.            management.  STD 16/RFC 1212 [13] defines a more concise
  71.            description mechanism, which is wholly consistent with
  72.            the SMI.
  73.  
  74.       o    RFC 1156 [4] which defines MIB-I, the core set of managed
  75.            objects for the Internet suite of protocols.  STD 17/RFC
  76.            1213 [6] defines MIB-II, an evolution of MIB-I based on
  77.            implementation experience and new operational
  78.            requirements.
  79.  
  80.       o    STD 15/RFC 1157 [5] which defines the SNMP, the protocol
  81.            used for network access to managed objects.
  82.  
  83.    The Framework permits new objects to be defined for the purpose of
  84.    experimentation and evaluation.
  85.  
  86. 1.1.  Object Definitions
  87.  
  88.    Managed objects are accessed via a virtual information store, termed
  89.    the Management Information Base or MIB.  Objects in the MIB are
  90.    defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
  91.    defined in the SMI [16].  In particular, each object object type is
  92.    named by an OBJECT IDENTIFIER, an administratively assigned name.
  93.    The object type together with an object instance serves to uniquely
  94.    identify a specific instantiation of the object.  For human
  95.    convenience, we often use a textual string, termed the descriptor, to
  96.    refer to the object type.
  97.  
  98. 2.  Change Log
  99.  
  100.    This section enumerates changes made to RFC 1398 to produce this
  101.    document.
  102.  
  103.     (1)   A section describing the applicability of various parts
  104.           of RFC 1573 to ethernet-like interfaces has been added.
  105.  
  106.     (2)   A minor error in the description of the TDR test was
  107.           fixed.
  108.  
  109.     (3)   A loopback test was defined to replace the standard
  110.           loopback test that was defined in RFC 1229.
  111.  
  112.  
  113.  
  114. Kastenholz                                                      [Page 2]
  115.  
  116. RFC 1623                   Ethernet-Like MIB                    May 1994
  117.  
  118.  
  119.     (4)   The description of dot3CollFrequencies was made a bit
  120.           clearer.
  121.  
  122.     (5)   A new object, EtherChipset, has been added. This object
  123.           replaces the ifExtnsChipSet object, which has been
  124.           removed per the Interface MIB Evolution effort.
  125.  
  126.     (6)   Several minor editorial changes, spelling corrections,
  127.           grammar and punctuation corrections, and so forth, were
  128.           made.
  129.  
  130. 3.  Overview
  131.  
  132.    Instances of these object types represent attributes of an interface
  133.    to an ethernet-like communications medium.  At present, ethernet-like
  134.    media are identified by three values of the ifType object in the
  135.    Internet-standard MIB:
  136.  
  137.          ethernet-csmacd(6)
  138.          iso88023-csmacd(7)
  139.          starLan(11)
  140.  
  141.    For these interfaces, the value of the ifSpecific variable in the
  142.    MIB-II [6] has the OBJECT IDENTIFIER value:
  143.  
  144.       dot3    OBJECT IDENTIFER ::= { experimental 3 }
  145.  
  146.    The definitions presented here are based on the IEEE 802.3 Layer
  147.    Management Specification [9], as originally interpreted by Frank
  148.    Kastenholz then of Interlan in [10].  Implementors of these MIB
  149.    objects should note that the IEEE document explicitly describes (in
  150.    the form of Pascal pseudocode) when, where, and how various MAC
  151.    attributes are measured.  The IEEE document also describes the
  152.    effects of MAC actions that may be invoked by manipulating instances
  153.    of the MIB objects defined here.
  154.  
  155.    To the extent that some of the attributes defined in [9] are
  156.    represented by previously defined objects in the Internet-standard
  157.    MIB or in the Generic Interface Extensions MIB [11], such attributes
  158.    are not redundantly represented by objects defined in this memo.
  159.    Among the attributes represented by objects defined in other memos
  160.    are the number of octets transmitted or received on a particular
  161.    interface, the number of frames transmitted or received on a
  162.    particular interface, the promiscuous status of an interface, the MAC
  163.    address of an interface, and multicast information associated with an
  164.    interface.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Kastenholz                                                      [Page 3]
  171.  
  172. RFC 1623                   Ethernet-Like MIB                    May 1994
  173.  
  174.  
  175. 3.1.  Relation to RFC 1213
  176.  
  177.    This section applies only when this MIB is used in conjunction with
  178.    the "old" (i.e., pre-RFC 1573) interface group.
  179.  
  180.    The relationship between an ethernet-like interface and an interface
  181.    in the context of the Internet-standard MIB is one-to-one.  As such,
  182.    the value of an ifIndex object instance can be directly used to
  183.    identify corresponding instances of the objects defined herein.
  184.  
  185. 3.2.  Relation to RFC 1573
  186.  
  187.    RFC 1573, the Interface MIB Evolution, requires that any MIB which is
  188.    an adjunct of the Interface MIB, clarify specific areas within the
  189.    Interface MIB.  These areas were intentionally left vague in RFC 1573
  190.    to avoid over constraining the MIB, thereby precluding management of
  191.    certain media-types.
  192.  
  193.    Section 3.3 of RFC 1573 enumerates several areas which a media-
  194.    specific MIB must clarify.  Each of these areas is addressed in a
  195.    following subsection.  The implementor is referred to RFC 1573 in
  196.    order to understand the general intent of these areas.
  197.  
  198. 3.2.1.  Layering Model
  199.  
  200.    This MIB does not provide for layering.  There are no sublayers.
  201.  
  202.    EDITOR'S NOTE:
  203.  
  204.       I could forsee the development of an 802.2 and enet-transceiver
  205.       MIB.  They could be higher and lower sublayers, respectively.  All
  206.       that THIS document should do is allude to the possibilities and
  207.       urge the implementor to be aware of the possibility and that they
  208.       may have requirements which supersede the requirements in this
  209.       document.
  210.  
  211. 3.2.2.  Virtual Circuits
  212.  
  213.    This medium does not support virtual circuits and this area is not
  214.    applicable to this MIB.
  215.  
  216. 3.2.3.  ifTestTable
  217.  
  218.    This MIB defines two tests for media which are instumented with this
  219.    MIB; TDR and Loopback.  Implementation of these tests is not
  220.    required.  Many common interface chips do not support one or both of
  221.    these tests.
  222.  
  223.  
  224.  
  225.  
  226. Kastenholz                                                      [Page 4]
  227.  
  228. RFC 1623                   Ethernet-Like MIB                    May 1994
  229.  
  230.  
  231.    These two tests are provided as a convenience, allowing a common
  232.    method to invoke the test.
  233.  
  234.    Standard MIBs do not include objects in which to return the results
  235.    of the TDR test.  Any needed objects MUST be provided in the vendor
  236.    specific MIB.
  237.  
  238. 3.2.4.  ifRcvAddressTable
  239.  
  240.    This table contains all IEEE 802.3 addresses, unicast, multicast, and
  241.    broadcast, for which this interface will receive packets and forward
  242.    them up to a higher layer entity for local consumption.  The format
  243.    of the address, contained in ifRcvAddressAddress, is the same as for
  244.    ifPhysAddress.
  245.  
  246.    In the event that the interface is part of a MAC bridge, this table
  247.    does not include unicast addresses which are accepted for possible
  248.    forwarding out some other port.  This table is explicitly not
  249.    intended to provide a bridge address filtering mechanism.
  250.  
  251. 3.2.5.  ifPhysAddress
  252.  
  253.    This object contains the IEEE 802.3 address which is placed in the
  254.    source-address field of any Ethernet, Starlan, or IEEE 802.3 frames
  255.    that originate at this interface.  Usually this will be kept in ROM
  256.    on the interface hardware.  Some systems may set this address via
  257.    software.
  258.  
  259.    In a system where there are several such addresses the designer has a
  260.    tougher choice.  The address chosen should be the one most likely to
  261.    be of use to network management (e.g.  the address placed in ARP
  262.    responses for systems which are primarily IP systems).
  263.  
  264.    If the designer truly can not chose, use of the factory- provided ROM
  265.    address is suggested.
  266.  
  267.    If the address can not be determined, an octet string of zero length
  268.    should be returned.
  269.  
  270.    The address is stored in binary in this object.  The address is
  271.    stored in "canonical" bit order, that is, the Group Bit is positioned
  272.    as the low-order bit of the first octet.  Thus, the first byte of a
  273.    multicast address would have the bit 0x01 set.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Kastenholz                                                      [Page 5]
  283.  
  284. RFC 1623                   Ethernet-Like MIB                    May 1994
  285.  
  286.  
  287. 3.2.6.  ifType
  288.  
  289.    This MIB applies to interfaces which have any of the following three
  290.    ifType values:
  291.  
  292.          ethernet-csmacd(6)
  293.          iso88023-csmacd(7)
  294.          starLan(11)
  295.  
  296.    Interfaces with any of these ifType values map to the EtherLike-MIB
  297.    in the same manner.  The EtherLike-MIB applies equally to all three
  298.    types; there are no implementation differences.
  299.  
  300. 4.  Definitions
  301.  
  302.    EtherLike-MIB DEFINITIONS ::= BEGIN
  303.  
  304.       IMPORTS
  305.           Counter, Gauge  FROM RFC1155-SMI
  306.           transmission    FROM RFC1213-MIB
  307.           OBJECT-TYPE     FROM RFC-1212;
  308.  
  309.        -- This MIB module uses the extended OBJECT-TYPE macro as
  310.        -- defined in RFC-1212.
  311.  
  312.       dot3    OBJECT IDENTIFIER ::= { transmission 7 }
  313.  
  314.       -- the Ethernet-like Statistics group
  315.  
  316.        dot3StatsTable  OBJECT-TYPE
  317.             SYNTAX     SEQUENCE OF Dot3StatsEntry
  318.             ACCESS     not-accessible
  319.             STATUS     mandatory
  320.             DESCRIPTION
  321.              "Statistics for a collection of ethernet-like
  322.              interfaces attached to a particular system."
  323.             ::= { dot3 2 }
  324.  
  325.  
  326.        dot3StatsEntry   OBJECT-TYPE
  327.             SYNTAX      Dot3StatsEntry
  328.             ACCESS      not-accessible
  329.             STATUS      mandatory
  330.             DESCRIPTION
  331.               "Statistics for a particular interface to an
  332.               ethernet-like medium."
  333.             INDEX     { dot3StatsIndex }
  334.             ::= { dot3StatsTable 1 }
  335.  
  336.  
  337.  
  338. Kastenholz                                                      [Page 6]
  339.  
  340. RFC 1623                   Ethernet-Like MIB                    May 1994
  341.  
  342.  
  343.        Dot3StatsEntry ::= SEQUENCE {
  344.             dot3StatsIndex                      INTEGER,
  345.             dot3StatsAlignmentErrors            Counter,
  346.             dot3StatsFCSErrors                  Counter,
  347.             dot3StatsSingleCollisionFrames      Counter,
  348.             dot3StatsMultipleCollisionFrames    Counter,
  349.             dot3StatsSQETestErrors              Counter,
  350.             dot3StatsDeferredTransmissions      Counter,
  351.             dot3StatsLateCollisions             Counter,
  352.             dot3StatsExcessiveCollisions        Counter,
  353.             dot3StatsInternalMacTransmitErrors  Counter,
  354.             dot3StatsCarrierSenseErrors         Counter,
  355.             dot3StatsFrameTooLongs              Counter,
  356.             dot3StatsInternalMacReceiveErrors   Counter
  357.        }
  358.  
  359.        dot3StatsIndex   OBJECT-TYPE
  360.             SYNTAX      INTEGER
  361.             ACCESS      read-only
  362.             STATUS      mandatory
  363.             DESCRIPTION
  364.               "An index value that uniquely identifies an
  365.               interface to an ethernet-like medium.  The
  366.               interface identified by a particular value of
  367.               this index is the same interface as identified
  368.               by the same value of ifIndex."
  369.             ::= { dot3StatsEntry 1 }
  370.  
  371.        dot3StatsAlignmentErrors   OBJECT-TYPE
  372.             SYNTAX     Counter
  373.             ACCESS     read-only
  374.             STATUS     mandatory
  375.             DESCRIPTION
  376.              "A count of frames received on a particular
  377.              interface that are not an integral number of
  378.              octets in length and do not pass the FCS check.
  379.  
  380.              The count represented by an instance of this
  381.              object is incremented when the alignmentError
  382.              status is returned by the MAC service to the
  383.              LLC (or other MAC user). Received frames for
  384.              which multiple error conditions obtain are,
  385.              according to the conventions of IEEE 802.3
  386.              Layer Management, counted exclusively according
  387.              to the error status presented to the LLC."
  388.             REFERENCE
  389.             "IEEE 802.3 Layer Management"
  390.             ::= { dot3StatsEntry 2 }
  391.  
  392.  
  393.  
  394. Kastenholz                                                      [Page 7]
  395.  
  396. RFC 1623                   Ethernet-Like MIB                    May 1994
  397.  
  398.  
  399.        dot3StatsFCSErrors   OBJECT-TYPE
  400.             SYNTAX      Counter
  401.             ACCESS      read-only
  402.             STATUS      mandatory
  403.             DESCRIPTION
  404.             "A count of frames received on a particular
  405.             interface that are an integral number of octets
  406.             in length but do not pass the FCS check.
  407.  
  408.             The count represented by an instance of this
  409.             object is incremented when the frameCheckError
  410.             status is returned by the MAC service to the
  411.             LLC (or other MAC user). Received frames for
  412.             which multiple error conditions obtain are,
  413.             according to the conventions of IEEE 802.3
  414.             Layer Management, counted exclusively according
  415.             to the error status presented to the LLC."
  416.             REFERENCE
  417.             "IEEE 802.3 Layer Management"
  418.             ::= { dot3StatsEntry 3 }
  419.  
  420.        dot3StatsSingleCollisionFrames   OBJECT-TYPE
  421.             SYNTAX      Counter
  422.             ACCESS      read-only
  423.             STATUS      mandatory
  424.             DESCRIPTION
  425.             "A count of successfully transmitted frames on
  426.             a particular interface for which transmission
  427.             is inhibited by exactly one collision.
  428.  
  429.             A frame that is counted by an instance of this
  430.             object is also counted by the corresponding
  431.             instance of either the ifOutUcastPkts,
  432.             ifOutMulticastPkts, or ifOutBroadcastPkts,
  433.             and is not counted by the corresponding
  434.             instance of the dot3StatsMultipleCollisionFrames
  435.             object."
  436.             REFERENCE
  437.             "IEEE 802.3 Layer Management"
  438.             ::= { dot3StatsEntry 4 }
  439.  
  440.        dot3StatsMultipleCollisionFrames   OBJECT-TYPE
  441.             SYNTAX      Counter
  442.             ACCESS      read-only
  443.             STATUS      mandatory
  444.             DESCRIPTION
  445.             "A count of successfully transmitted frames on
  446.             a particular interface for which transmission
  447.  
  448.  
  449.  
  450. Kastenholz                                                      [Page 8]
  451.  
  452. RFC 1623                   Ethernet-Like MIB                    May 1994
  453.  
  454.  
  455.              is inhibited by more than one collision.
  456.  
  457.             A frame that is counted by an instance of this
  458.             object is also counted by the corresponding
  459.             instance of either the ifOutUcastPkts,
  460.             ifOutMulticastPkts, or ifOutBroadcastPkts,
  461.             and is not counted by the corresponding
  462.             instance of the dot3StatsSingleCollisionFrames
  463.             object."
  464.             REFERENCE
  465.             "IEEE 802.3 Layer Management"
  466.             ::= { dot3StatsEntry 5 }
  467.  
  468.        dot3StatsSQETestErrors   OBJECT-TYPE
  469.             SYNTAX     Counter
  470.             ACCESS     read-only
  471.             STATUS     mandatory
  472.             DESCRIPTION
  473.             "A count of times that the SQE TEST ERROR
  474.             message is generated by the PLS sublayer for a
  475.             particular interface. The SQE TEST ERROR
  476.             message is defined in section 7.2.2.2.4 of
  477.             ANSI/IEEE 802.3-1985 and its generation is
  478.             described in section 7.2.4.6 of the same
  479.             document."
  480.             REFERENCE
  481.             "ANSI/IEEE Std 802.3-1985 Carrier Sense
  482.             Multiple Access with Collision Detection Access
  483.             Method and Physical Layer Specifications"
  484.             ::= { dot3StatsEntry 6 }
  485.  
  486.        dot3StatsDeferredTransmissions   OBJECT-TYPE
  487.             SYNTAX      Counter
  488.             ACCESS      read-only
  489.             STATUS      mandatory
  490.             DESCRIPTION
  491.             "A count of frames for which the first
  492.             transmission attempt on a particular interface
  493.             is delayed because the medium is busy.
  494.  
  495.             The count represented by an instance of this
  496.             object does not include frames involved in
  497.             collisions."
  498.             REFERENCE
  499.             "IEEE 802.3 Layer Management"
  500.             ::= { dot3StatsEntry 7 }
  501.  
  502.        dot3StatsLateCollisions   OBJECT-TYPE
  503.  
  504.  
  505.  
  506. Kastenholz                                                      [Page 9]
  507.  
  508. RFC 1623                   Ethernet-Like MIB                    May 1994
  509.  
  510.  
  511.             SYNTAX      Counter
  512.             ACCESS      read-only
  513.             STATUS      mandatory
  514.             DESCRIPTION
  515.             "The number of times that a collision is
  516.             detected on a particular interface later than
  517.             512 bit-times into the transmission of a
  518.             packet.
  519.  
  520.             Five hundred and twelve bit-times corresponds
  521.             to 51.2 microseconds on a 10 Mbit/s system. A
  522.             (late) collision included in a count
  523.             represented by an instance of this object is
  524.             also considered as a (generic) collision for
  525.             purposes of other collision-related
  526.             statistics."
  527.             REFERENCE
  528.             "IEEE 802.3 Layer Management"
  529.             ::= { dot3StatsEntry 8 }
  530.  
  531.        dot3StatsExcessiveCollisions   OBJECT-TYPE
  532.             SYNTAX    Counter
  533.             ACCESS    read-only
  534.             STATUS    mandatory
  535.             DESCRIPTION
  536.             "A count of frames for which transmission on a
  537.             particular interface fails due to excessive
  538.             collisions."
  539.             REFERENCE
  540.             "IEEE 802.3 Layer Management"
  541.             ::= { dot3StatsEntry 9 }
  542.  
  543.  
  544.        dot3StatsInternalMacTransmitErrors   OBJECT-TYPE
  545.             SYNTAX    Counter
  546.             ACCESS    read-only
  547.             STATUS    mandatory
  548.             DESCRIPTION
  549.             "A count of frames for which transmission on a
  550.             particular interface fails due to an internal
  551.             MAC sublayer transmit error. A frame is only
  552.             counted by an instance of this object if it is
  553.             not counted by the corresponding instance of
  554.             either the dot3StatsLateCollisions object, the
  555.             dot3StatsExcessiveCollisions object, or the
  556.             dot3StatsCarrierSenseErrors object.
  557.  
  558.             The precise meaning of the count represented by
  559.  
  560.  
  561.  
  562. Kastenholz                                                     [Page 10]
  563.  
  564. RFC 1623                   Ethernet-Like MIB                    May 1994
  565.  
  566.  
  567.             an instance of this object is implementation-
  568.             specific.  In particular, an instance of this
  569.             object may represent a count of transmission
  570.             errors on a particular interface that are not
  571.             otherwise counted."
  572.             REFERENCE
  573.             "IEEE 802.3 Layer Management"
  574.             ::= { dot3StatsEntry 10 }
  575.  
  576.        dot3StatsCarrierSenseErrors   OBJECT-TYPE
  577.             SYNTAX    Counter
  578.             ACCESS    read-only
  579.             STATUS    mandatory
  580.             DESCRIPTION
  581.             "The number of times that the carrier sense
  582.             condition was lost or never asserted when
  583.             attempting to transmit a frame on a particular
  584.             interface.
  585.  
  586.             The count represented by an instance of this
  587.             object is incremented at most once per
  588.             transmission attempt, even if the carrier sense
  589.             condition fluctuates during a transmission
  590.             attempt."
  591.             REFERENCE
  592.             "IEEE 802.3 Layer Management"
  593.             ::= { dot3StatsEntry 11 }
  594.  
  595.        -- { dot3StatsEntry 12 } is not assigned
  596.  
  597.        dot3StatsFrameTooLongs   OBJECT-TYPE
  598.             SYNTAX    Counter
  599.             ACCESS    read-only
  600.             STATUS    mandatory
  601.             DESCRIPTION
  602.             "A count of frames received on a particular
  603.             interface that exceed the maximum permitted
  604.             frame size.
  605.  
  606.             The count represented by an instance of this
  607.             object is incremented when the frameTooLong
  608.             status is returned by the MAC service to the
  609.             LLC (or other MAC user). Received frames for
  610.             which multiple error conditions obtain are,
  611.             according to the conventions of IEEE 802.3
  612.             Layer Management, counted exclusively according
  613.             to the error status presented to the LLC."
  614.             REFERENCE
  615.  
  616.  
  617.  
  618. Kastenholz                                                     [Page 11]
  619.  
  620. RFC 1623                   Ethernet-Like MIB                    May 1994
  621.  
  622.  
  623.             "IEEE 802.3 Layer Management"
  624.             ::= { dot3StatsEntry 13 }
  625.  
  626.        -- { dot3StatsEntry 14 } is not assigned
  627.  
  628.        -- { dot3StatsEntry 15 } is not assigned
  629.  
  630.        dot3StatsInternalMacReceiveErrors   OBJECT-TYPE
  631.             SYNTAX    Counter
  632.             ACCESS    read-only
  633.             STATUS    mandatory
  634.             DESCRIPTION
  635.             "A count of frames for which reception on a
  636.             particular interface fails due to an internal
  637.             MAC sublayer receive error. A frame is only
  638.             counted by an instance of this object if it is
  639.             not counted by the corresponding instance of
  640.             either the dot3StatsFrameTooLongs object, the
  641.             dot3StatsAlignmentErrors object, or the
  642.             dot3StatsFCSErrors object.
  643.  
  644.             The precise meaning of the count represented by
  645.             an instance of this object is implementation-
  646.             specific.  In particular, an instance of this
  647.             object may represent a count of receive errors
  648.             on a particular interface that are not
  649.             otherwise counted."
  650.             REFERENCE
  651.             "IEEE 802.3 Layer Management"
  652.             ::= { dot3StatsEntry 16 }
  653.  
  654.        dot3StatsEtherChipSet   OBJECT-TYPE
  655.             SYNTAX        OBJECT IDENTIFIER
  656.             ACCESS        read-only
  657.             STATUS        mandatory
  658.             DESCRIPTION
  659.             "This object contains an OBJECT IDENTIFIER
  660.             which identifies the chipset used to
  661.             realize the interface. Ethernet-like
  662.             interfaces are typically built out of
  663.             several different chips. The MIB implementor
  664.             is presented with a decision of which chip
  665.             to identify via this object. The implementor
  666.             should identify the chip which is usually
  667.             called the Medium Access Control chip.
  668.             If no such chip is easily identifiable,
  669.             the implementor should identify the chip
  670.             which actually gathers the transmit
  671.  
  672.  
  673.  
  674. Kastenholz                                                     [Page 12]
  675.  
  676. RFC 1623                   Ethernet-Like MIB                    May 1994
  677.  
  678.  
  679.             and receive statistics and error
  680.             indications. This would allow a
  681.             manager station to correlate the
  682.             statistics and the chip generating
  683.             them, giving it the ability to take
  684.             into account any known anomalies
  685.             in the chip."
  686.             ::= { dot3StatsEntry 17 }
  687.  
  688.        -- the Ethernet-like Collision Statistics group
  689.  
  690.        -- Implementation of this group is optional; it is appropriate
  691.        -- for all systems which have the necessary metering
  692.  
  693.        dot3CollTable  OBJECT-TYPE
  694.             SYNTAX    SEQUENCE OF Dot3CollEntry
  695.             ACCESS    not-accessible
  696.             STATUS    mandatory
  697.             DESCRIPTION
  698.             "A collection of collision histograms for a
  699.             particular set of interfaces."
  700.             ::= { dot3 5 }
  701.  
  702.  
  703.        dot3CollEntry  OBJECT-TYPE
  704.             SYNTAX    Dot3CollEntry
  705.             ACCESS    not-accessible
  706.             STATUS    mandatory
  707.             DESCRIPTION
  708.             "A cell in the histogram of per-frame
  709.             collisions for a particular interface.  An
  710.             instance of this object represents the
  711.             frequency of individual MAC frames for which
  712.             the transmission (successful or otherwise) on a
  713.             particular interface is accompanied by a
  714.             particular number of media collisions."
  715.             INDEX     { ifIndex, dot3CollCount }
  716.             ::= { dot3CollTable 1 }
  717.  
  718.        Dot3CollEntry ::= SEQUENCE {
  719.             dot3CollCount        INTEGER,
  720.             dot3CollFrequencies  Counter
  721.        }
  722.  
  723.        -- { dot3CollEntry 1 } is no longer in use
  724.  
  725.        dot3CollCount  OBJECT-TYPE
  726.             SYNTAX    INTEGER (1..16)
  727.  
  728.  
  729.  
  730. Kastenholz                                                     [Page 13]
  731.  
  732. RFC 1623                   Ethernet-Like MIB                    May 1994
  733.  
  734.  
  735.             ACCESS    not-accessible
  736.             STATUS    mandatory
  737.             DESCRIPTION
  738.             "The number of per-frame media collisions for
  739.             which a particular collision histogram cell
  740.             represents the frequency on a particular
  741.             interface."
  742.             ::= { dot3CollEntry 2 }
  743.  
  744.  
  745.        dot3CollFrequencies   OBJECT-TYPE
  746.             SYNTAX    Counter
  747.             ACCESS    read-only
  748.             STATUS    mandatory
  749.             DESCRIPTION
  750.             "A count of individual MAC frames for which the
  751.             transmission (successful or otherwise) on a
  752.             particular interface occurs after the
  753.             frame has experienced exactly the number
  754.             of collisions in the associated
  755.             dot3CollCount object.
  756.  
  757.             For example, a frame which is transmitted
  758.             on interface 77 after experiencing
  759.             exactly 4 collisions would be indicated
  760.             by incrementing only dot3CollFrequencies.77.4.
  761.             No other instance of dot3CollFrequencies would
  762.             be incremented in this example."
  763.             ::= { dot3CollEntry 3 }
  764.  
  765.        --  802.3 Tests
  766.  
  767.        dot3Tests   OBJECT IDENTIFIER ::= { dot3 6 }
  768.  
  769.        dot3Errors  OBJECT IDENTIFIER ::= { dot3 7 }
  770.  
  771.  
  772.        --  TDR Test
  773.  
  774.        -- The Time-Domain Reflectometry (TDR) test is specific
  775.        -- to ethernet-like interfaces with the exception of
  776.        -- 10BaseT and 10BaseF. The TDR value may be useful
  777.        -- in determining the approximate distance to a cable fault.
  778.        -- It is advisable to repeat this test to check for a
  779.        -- consistent resulting TDR value, to verify that there
  780.        -- is a fault.
  781.  
  782.        dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 }
  783.  
  784.  
  785.  
  786. Kastenholz                                                     [Page 14]
  787.  
  788. RFC 1623                   Ethernet-Like MIB                    May 1994
  789.  
  790.  
  791.        -- A TDR test returns as its result the time interval,
  792.        -- measured in 10 MHz ticks or 100 nsec units, between
  793.        -- the start of TDR test transmission and the subsequent
  794.        -- detection of a collision or deassertion of carrier.  On
  795.        -- successful completion of a TDR test, the result is
  796.        -- stored as the value of the appropriate instance of the
  797.        -- MIB object dot3TestTdrValue, and the OBJECT IDENTIFIER
  798.        -- of that instanceis stored in the corresponding instance
  799.        -- of ifExtnsTestCode (thereby indicating where the
  800.        -- result has been stored).
  801.  
  802.  
  803.        -- Loopback Test
  804.  
  805.        -- Another test is the full-duplex loopback test.
  806.        -- This test configures the MAC chip and executes
  807.        -- an internal loopback test of memory, data paths,
  808.        -- and the MAC chip logic.  This loopback test can
  809.        -- only be executed if the interface is offline.
  810.        -- Once the test has completed, the MAC chip should
  811.        -- be reinitialized for network operation, but it
  812.        -- should remain offline.
  813.  
  814.        dot3TestLoopBack OBJECT IDENTIFIER ::= { dot3Tests 2 }
  815.  
  816.        -- If an error occurs during a test, the object
  817.        -- ifTestResult (defined in RFC1573) will be set
  818.        -- to failed(7).  The following two OBJECT
  819.        -- IDENTIFIERs may be used to provided more
  820.        -- information as values for ifTestCode.
  821.  
  822.                 -- couldn't initialize MAC chip for test
  823.        dot3ErrorInitError     OBJECT IDENTIFIER ::= { dot3Errors 1 }
  824.  
  825.                 -- expected data not received (or not
  826.                 -- received correctly) in loopback test
  827.        dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 }
  828.  
  829.        -- RFC1573 does away with the interface chipset object.
  830.        -- The following OBJECT IDENTIFIER definitions are
  831.        -- retained for purposes of backwards compatibility
  832.        -- with pre-RFC1573 systems.
  833.        --  802.3 Hardware Chipsets
  834.  
  835.        -- The object ifExtnsChipSet is provided in RFC1229 to
  836.        -- identify the MAC hardware used to communcate on an
  837.        -- interface.  The following hardware chipsets are
  838.        -- provided for 802.3:
  839.  
  840.  
  841.  
  842. Kastenholz                                                     [Page 15]
  843.  
  844. RFC 1623                   Ethernet-Like MIB                    May 1994
  845.  
  846.  
  847.        dot3ChipSets          OBJECT IDENTIFIER ::= { dot3 8 }
  848.        dot3ChipSetAMD        OBJECT IDENTIFIER ::= { dot3ChipSets 1 }
  849.        dot3ChipSetAMD7990    OBJECT IDENTIFIER ::= { dot3ChipSetAMD 1 }
  850.        dot3ChipSetAMD79900   OBJECT IDENTIFIER ::= { dot3ChipSetAMD 2 }
  851.        dot3ChipSetAMD79C940  OBJECT IDENTIFIER ::= { dot3ChipSetAMD 3 }
  852.  
  853.        dot3ChipSetIntel      OBJECT IDENTIFIER ::= { dot3ChipSets 2 }
  854.        dot3ChipSetIntel82586 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 1 }
  855.        dot3ChipSetIntel82596 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 2 }
  856.  
  857.        dot3ChipSetSeeq       OBJECT IDENTIFIER ::= { dot3ChipSets 3 }
  858.        dot3ChipSetSeeq8003   OBJECT IDENTIFIER ::= { dot3ChipSetSeeq 1 }
  859.  
  860.        dot3ChipSetNational      OBJECT IDENTIFIER ::= { dot3ChipSets 4 }
  861.        dot3ChipSetNational8390  OBJECT IDENTIFIER ::=
  862.                                   { dot3ChipSetNational 1 }
  863.        dot3ChipSetNationalSonic OBJECT IDENTIFIER ::=
  864.                                   { dot3ChipSetNational 2 }
  865.  
  866.        dot3ChipSetFujitsu       OBJECT IDENTIFIER ::= { dot3ChipSets 5 }
  867.        dot3ChipSetFujitsu86950  OBJECT IDENTIFIER ::=
  868.                                   { dot3ChipSetFujitsu 1 }
  869.  
  870.        dot3ChipSetDigital       OBJECT IDENTIFIER ::= { dot3ChipSets 6 }
  871.        dot3ChipSetDigitalDC21040  OBJECT IDENTIFIER ::=
  872.                                   { dot3ChipSetDigital 1 }
  873.  
  874.        -- For those chipsets not represented above, OBJECT IDENTIFIER
  875.        -- assignment is required in other documentation, e.g., assignment
  876.        -- within that part of the registration tree delegated to
  877.        -- individual enterprises (see RFC1155).
  878.  
  879.    END
  880.  
  881. 5.  Acknowledgements
  882.  
  883.    This document was produced by the Ethernet MIB Working Group.
  884.  
  885.    This document is based on the Proposed Standard Ethernet MIB, RFC
  886.    1284 [14], of which Jihn Cook of Chipcom was the editor.  The
  887.    Ethernet MIB Working Group gathered implementation experience of the
  888.    variables specified in RFC 1284 and used that information to develop
  889.    this revised MIB.
  890.  
  891.    RFC 1284, in turn, is based on a document written by Frank Kastenholz
  892.    of Interlan entitled IEEE 802.3 Layer Management Draft M compatible
  893.    MIB for TCP/IP Networks [10].  This document has been modestly
  894.    reworked, initially by the SNMP Working Group, and then by the
  895.  
  896.  
  897.  
  898. Kastenholz                                                     [Page 16]
  899.  
  900. RFC 1623                   Ethernet-Like MIB                    May 1994
  901.  
  902.  
  903.    Transmission Working Group, to reflect the current conventions for
  904.    defining objects for MIB interfaces.  James Davin, of the MIT
  905.    Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN
  906.    Systems, contributed to later drafts of this memo. Marshall Rose of
  907.    Performance Systems International, Inc. converted the document into
  908.    its current concise format. Anil Rijsinghani of DEC contributed text
  909.    that more adequately describes the TDR test.  Thanks to Frank
  910.    Kastenholz of Interlan and Louis Steinberg of IBM for their
  911.    experimentation.
  912.  
  913. 6.  References
  914.  
  915.    [1] Cerf, V., "IAB Recommendations for the Development of Internet
  916.        Network Management Standards", RFC 1052, NRI, April 1988.
  917.  
  918.    [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
  919.        Group", RFC 1109, NRI, August 1989.
  920.  
  921.    [3] Rose M., and K. McCloghrie, "Structure and Identification of
  922.        Management Information for TCP/IP-based internets", STD 16, RFC
  923.        1155, Performance Systems International, Hughes LAN Systems, May
  924.        1990.
  925.  
  926.    [4] McCloghrie K., and M. Rose, "Management Information Base for
  927.        Network Management of TCP/IP-based internets", RFC 1156, Hughes
  928.        LAN Systems, Performance Systems International, May 1990.
  929.  
  930.    [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
  931.        Network Management Protocol", STD 15, RFC 1157, SNMP Research,
  932.        Performance Systems International, Performance Systems
  933.        International, MIT Laboratory for Computer Science, May 1990.
  934.  
  935.    [6] McCloghrie K., and M. Rose, Editors, "Management Information Base
  936.        for Network Management of TCP/IP-based internets", STD 17, RFC
  937.        1213, Performance Systems International, March 1991.
  938.  
  939.    [7] Information processing systems - Open Systems Interconnection -
  940.        Specification of Abstract Syntax Notation One (ASN.1),
  941.        International Organization for Standardization, International
  942.        Standard 8824, December 1987.
  943.  
  944.    [8] Information processing systems - Open Systems Interconnection -
  945.        Specification of Basic Encoding Rules for Abstract Notation One
  946.        (ASN.1), International Organization for Standardization,
  947.        International Standard 8825, December 1987.
  948.  
  949.    [9] IEEE, "IEEE 802.3 Layer Management", November 1988.
  950.  
  951.  
  952.  
  953.  
  954. Kastenholz                                                     [Page 17]
  955.  
  956. RFC 1623                   Ethernet-Like MIB                    May 1994
  957.  
  958.  
  959.   [10] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible MIB
  960.        for TCP/IP Networks", electronic mail message to mib-
  961.        wg@nnsc.nsf.net, 9 June 1989.
  962.  
  963.   [11] McCloghrie, K., Editor, "Extensions to the Generic-Interface
  964.        MIB", RFC 1229, Hughes LAN Systems, Inc., May 1991.
  965.  
  966.   [12] IEEE, "Carrier Sense Multiple Access with Collision Detection
  967.        (CSMA/CD) Access Method and Physical Layer Specifications",
  968.        ANSI/IEEE Std 802.3-1985.
  969.  
  970.   [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
  971.        RFC 1212, Performance Systems International, Hughes LAN Systems,
  972.        March 1991.
  973.  
  974.   [14] Cook, J., Editor, "Definitions of Managed Objects for Ethernet-
  975.        Like Interface Types", RFC 1284, Chipcom Corporation, December
  976.        1991.
  977.  
  978.   [15] Kastenholz, F., "Definitions of Managed Objects for the Etheret-
  979.        like Interface Types", RFC 1398, FTP Software, Inc., January
  980.        1993.
  981.  
  982.   [16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
  983.        of Management Information for version 2 of the Simple Network
  984.        Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
  985.        Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  986.        University, April 1993.
  987.  
  988.   [17] Galvin, J., and K. McCloghrie, "Administrative Model for version
  989.        2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
  990.        Trusted Information Systems, Hughes LAN Systems, April 1993.
  991.  
  992.   [18] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
  993.        Operations for version 2 of the Simple Network Management
  994.        Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
  995.        Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  996.        University, April 1993.
  997.  
  998.   [19] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces
  999.        Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software,
  1000.        January 1994.
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Kastenholz                                                     [Page 18]
  1011.  
  1012. RFC 1623                   Ethernet-Like MIB                    May 1994
  1013.  
  1014.  
  1015. 7.  Security Considerations
  1016.  
  1017.    Security issues are not discussed in this memo.
  1018.  
  1019. 8.  Author's Address
  1020.  
  1021.    Frank Kastenholz
  1022.    FTP Software, Inc.
  1023.    2 High Street
  1024.    North Andover, Mass, USA 01845
  1025.  
  1026.    Phone: 508-685-4000
  1027.    EMail: kasten@ftp.com
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Kastenholz                                                     [Page 19]
  1067.  
  1068.