home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1643 < prev    next >
Text File  |  1994-07-13  |  39KB  |  1,068 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      F. Kastenholz
  8. Request for Comments: 1643                            FTP Software, Inc.
  9. Obsoletes: 1623, 1398                                          July 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 versions of this MIB: RFC 1623 [20], and RFC
  54.    1398 [15].
  55.  
  56.  
  57.  
  58. Kastenholz                                                      [Page 1]
  59.  
  60. RFC 1643                   Ethernet-Like MIB                   July 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 1643                   Ethernet-Like MIB                   July 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 ::= { transmission 7 }
  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 1643                   Ethernet-Like MIB                   July 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 1643                   Ethernet-Like MIB                   July 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 1643                   Ethernet-Like MIB                   July 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.           ifIndex, 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 1643                   Ethernet-Like MIB                   July 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.             dot3StatsEtherChipSet               OBJECT IDENTIFIER
  358.        }
  359.  
  360.        dot3StatsIndex   OBJECT-TYPE
  361.             SYNTAX      INTEGER
  362.             ACCESS      read-only
  363.             STATUS      mandatory
  364.             DESCRIPTION
  365.               "An index value that uniquely identifies an
  366.               interface to an ethernet-like medium.  The
  367.               interface identified by a particular value of
  368.               this index is the same interface as identified
  369.               by the same value of ifIndex."
  370.             ::= { dot3StatsEntry 1 }
  371.  
  372.        dot3StatsAlignmentErrors   OBJECT-TYPE
  373.             SYNTAX     Counter
  374.             ACCESS     read-only
  375.             STATUS     mandatory
  376.             DESCRIPTION
  377.              "A count of frames received on a particular
  378.              interface that are not an integral number of
  379.              octets in length and do not pass the FCS check.
  380.  
  381.              The count represented by an instance of this
  382.              object is incremented when the alignmentError
  383.              status is returned by the MAC service to the
  384.              LLC (or other MAC user). Received frames for
  385.              which multiple error conditions obtain are,
  386.              according to the conventions of IEEE 802.3
  387.              Layer Management, counted exclusively according
  388.              to the error status presented to the LLC."
  389.             REFERENCE
  390.             "IEEE 802.3 Layer Management"
  391.  
  392.  
  393.  
  394. Kastenholz                                                      [Page 7]
  395.  
  396. RFC 1643                   Ethernet-Like MIB                   July 1994
  397.  
  398.  
  399.             ::= { dot3StatsEntry 2 }
  400.  
  401.        dot3StatsFCSErrors   OBJECT-TYPE
  402.             SYNTAX      Counter
  403.             ACCESS      read-only
  404.             STATUS      mandatory
  405.             DESCRIPTION
  406.             "A count of frames received on a particular
  407.             interface that are an integral number of octets
  408.             in length but do not pass the FCS check.
  409.  
  410.             The count represented by an instance of this
  411.             object is incremented when the frameCheckError
  412.             status is returned by the MAC service to the
  413.             LLC (or other MAC user). Received frames for
  414.             which multiple error conditions obtain are,
  415.             according to the conventions of IEEE 802.3
  416.             Layer Management, counted exclusively according
  417.             to the error status presented to the LLC."
  418.             REFERENCE
  419.             "IEEE 802.3 Layer Management"
  420.             ::= { dot3StatsEntry 3 }
  421.  
  422.        dot3StatsSingleCollisionFrames   OBJECT-TYPE
  423.             SYNTAX      Counter
  424.             ACCESS      read-only
  425.             STATUS      mandatory
  426.             DESCRIPTION
  427.             "A count of successfully transmitted frames on
  428.             a particular interface for which transmission
  429.             is inhibited by exactly one collision.
  430.  
  431.             A frame that is counted by an instance of this
  432.             object is also counted by the corresponding
  433.             instance of either the ifOutUcastPkts,
  434.             ifOutMulticastPkts, or ifOutBroadcastPkts,
  435.             and is not counted by the corresponding
  436.             instance of the dot3StatsMultipleCollisionFrames
  437.             object."
  438.             REFERENCE
  439.             "IEEE 802.3 Layer Management"
  440.             ::= { dot3StatsEntry 4 }
  441.  
  442.        dot3StatsMultipleCollisionFrames   OBJECT-TYPE
  443.             SYNTAX      Counter
  444.             ACCESS      read-only
  445.             STATUS      mandatory
  446.             DESCRIPTION
  447.  
  448.  
  449.  
  450. Kastenholz                                                      [Page 8]
  451.  
  452. RFC 1643                   Ethernet-Like MIB                   July 1994
  453.  
  454.  
  455.             "A count of successfully transmitted frames on
  456.             a particular interface for which transmission
  457.              is inhibited by more than one collision.
  458.  
  459.             A frame that is counted by an instance of this
  460.             object is also counted by the corresponding
  461.             instance of either the ifOutUcastPkts,
  462.             ifOutMulticastPkts, or ifOutBroadcastPkts,
  463.             and is not counted by the corresponding
  464.             instance of the dot3StatsSingleCollisionFrames
  465.             object."
  466.             REFERENCE
  467.             "IEEE 802.3 Layer Management"
  468.             ::= { dot3StatsEntry 5 }
  469.  
  470.        dot3StatsSQETestErrors   OBJECT-TYPE
  471.             SYNTAX     Counter
  472.             ACCESS     read-only
  473.             STATUS     mandatory
  474.             DESCRIPTION
  475.             "A count of times that the SQE TEST ERROR
  476.             message is generated by the PLS sublayer for a
  477.             particular interface. The SQE TEST ERROR
  478.             message is defined in section 7.2.2.2.4 of
  479.             ANSI/IEEE 802.3-1985 and its generation is
  480.             described in section 7.2.4.6 of the same
  481.             document."
  482.             REFERENCE
  483.             "ANSI/IEEE Std 802.3-1985 Carrier Sense
  484.             Multiple Access with Collision Detection Access
  485.             Method and Physical Layer Specifications"
  486.             ::= { dot3StatsEntry 6 }
  487.  
  488.        dot3StatsDeferredTransmissions   OBJECT-TYPE
  489.             SYNTAX      Counter
  490.             ACCESS      read-only
  491.             STATUS      mandatory
  492.             DESCRIPTION
  493.             "A count of frames for which the first
  494.             transmission attempt on a particular interface
  495.             is delayed because the medium is busy.
  496.  
  497.             The count represented by an instance of this
  498.             object does not include frames involved in
  499.             collisions."
  500.             REFERENCE
  501.             "IEEE 802.3 Layer Management"
  502.             ::= { dot3StatsEntry 7 }
  503.  
  504.  
  505.  
  506. Kastenholz                                                      [Page 9]
  507.  
  508. RFC 1643                   Ethernet-Like MIB                   July 1994
  509.  
  510.  
  511.        dot3StatsLateCollisions   OBJECT-TYPE
  512.             SYNTAX      Counter
  513.             ACCESS      read-only
  514.             STATUS      mandatory
  515.             DESCRIPTION
  516.             "The number of times that a collision is
  517.             detected on a particular interface later than
  518.             512 bit-times into the transmission of a
  519.             packet.
  520.  
  521.             Five hundred and twelve bit-times corresponds
  522.             to 51.2 microseconds on a 10 Mbit/s system. A
  523.             (late) collision included in a count
  524.             represented by an instance of this object is
  525.             also considered as a (generic) collision for
  526.             purposes of other collision-related
  527.             statistics."
  528.             REFERENCE
  529.             "IEEE 802.3 Layer Management"
  530.             ::= { dot3StatsEntry 8 }
  531.  
  532.        dot3StatsExcessiveCollisions   OBJECT-TYPE
  533.             SYNTAX    Counter
  534.             ACCESS    read-only
  535.             STATUS    mandatory
  536.             DESCRIPTION
  537.             "A count of frames for which transmission on a
  538.             particular interface fails due to excessive
  539.             collisions."
  540.             REFERENCE
  541.             "IEEE 802.3 Layer Management"
  542.             ::= { dot3StatsEntry 9 }
  543.  
  544.  
  545.        dot3StatsInternalMacTransmitErrors   OBJECT-TYPE
  546.             SYNTAX    Counter
  547.             ACCESS    read-only
  548.             STATUS    mandatory
  549.             DESCRIPTION
  550.             "A count of frames for which transmission on a
  551.             particular interface fails due to an internal
  552.             MAC sublayer transmit error. A frame is only
  553.             counted by an instance of this object if it is
  554.             not counted by the corresponding instance of
  555.             either the dot3StatsLateCollisions object, the
  556.             dot3StatsExcessiveCollisions object, or the
  557.             dot3StatsCarrierSenseErrors object.
  558.  
  559.  
  560.  
  561.  
  562. Kastenholz                                                     [Page 10]
  563.  
  564. RFC 1643                   Ethernet-Like MIB                   July 1994
  565.  
  566.  
  567.             The precise meaning of the count represented by
  568.             an instance of this object is implementation-
  569.             specific.  In particular, an instance of this
  570.             object may represent a count of transmission
  571.             errors on a particular interface that are not
  572.             otherwise counted."
  573.             REFERENCE
  574.             "IEEE 802.3 Layer Management"
  575.             ::= { dot3StatsEntry 10 }
  576.  
  577.        dot3StatsCarrierSenseErrors   OBJECT-TYPE
  578.             SYNTAX    Counter
  579.             ACCESS    read-only
  580.             STATUS    mandatory
  581.             DESCRIPTION
  582.             "The number of times that the carrier sense
  583.             condition was lost or never asserted when
  584.             attempting to transmit a frame on a particular
  585.             interface.
  586.  
  587.             The count represented by an instance of this
  588.             object is incremented at most once per
  589.             transmission attempt, even if the carrier sense
  590.             condition fluctuates during a transmission
  591.             attempt."
  592.             REFERENCE
  593.             "IEEE 802.3 Layer Management"
  594.             ::= { dot3StatsEntry 11 }
  595.  
  596.        -- { dot3StatsEntry 12 } is not assigned
  597.  
  598.        dot3StatsFrameTooLongs   OBJECT-TYPE
  599.             SYNTAX    Counter
  600.             ACCESS    read-only
  601.             STATUS    mandatory
  602.             DESCRIPTION
  603.             "A count of frames received on a particular
  604.             interface that exceed the maximum permitted
  605.             frame size.
  606.  
  607.             The count represented by an instance of this
  608.             object is incremented when the frameTooLong
  609.             status is returned by the MAC service to the
  610.             LLC (or other MAC user). Received frames for
  611.             which multiple error conditions obtain are,
  612.             according to the conventions of IEEE 802.3
  613.             Layer Management, counted exclusively according
  614.             to the error status presented to the LLC."
  615.  
  616.  
  617.  
  618. Kastenholz                                                     [Page 11]
  619.  
  620. RFC 1643                   Ethernet-Like MIB                   July 1994
  621.  
  622.  
  623.             REFERENCE
  624.             "IEEE 802.3 Layer Management"
  625.             ::= { dot3StatsEntry 13 }
  626.  
  627.        -- { dot3StatsEntry 14 } is not assigned
  628.  
  629.        -- { dot3StatsEntry 15 } is not assigned
  630.  
  631.        dot3StatsInternalMacReceiveErrors   OBJECT-TYPE
  632.             SYNTAX    Counter
  633.             ACCESS    read-only
  634.             STATUS    mandatory
  635.             DESCRIPTION
  636.             "A count of frames for which reception on a
  637.             particular interface fails due to an internal
  638.             MAC sublayer receive error. A frame is only
  639.             counted by an instance of this object if it is
  640.             not counted by the corresponding instance of
  641.             either the dot3StatsFrameTooLongs object, the
  642.             dot3StatsAlignmentErrors object, or the
  643.             dot3StatsFCSErrors object.
  644.  
  645.             The precise meaning of the count represented by
  646.             an instance of this object is implementation-
  647.             specific.  In particular, an instance of this
  648.             object may represent a count of receive errors
  649.             on a particular interface that are not
  650.             otherwise counted."
  651.             REFERENCE
  652.             "IEEE 802.3 Layer Management"
  653.             ::= { dot3StatsEntry 16 }
  654.  
  655.        dot3StatsEtherChipSet   OBJECT-TYPE
  656.             SYNTAX        OBJECT IDENTIFIER
  657.             ACCESS        read-only
  658.             STATUS        mandatory
  659.             DESCRIPTION
  660.             "This object contains an OBJECT IDENTIFIER
  661.             which identifies the chipset used to
  662.             realize the interface. Ethernet-like
  663.             interfaces are typically built out of
  664.             several different chips. The MIB implementor
  665.             is presented with a decision of which chip
  666.             to identify via this object. The implementor
  667.             should identify the chip which is usually
  668.             called the Medium Access Control chip.
  669.             If no such chip is easily identifiable,
  670.             the implementor should identify the chip
  671.  
  672.  
  673.  
  674. Kastenholz                                                     [Page 12]
  675.  
  676. RFC 1643                   Ethernet-Like MIB                   July 1994
  677.  
  678.  
  679.             which actually gathers the transmit
  680.             and receive statistics and error
  681.             indications. This would allow a
  682.             manager station to correlate the
  683.             statistics and the chip generating
  684.             them, giving it the ability to take
  685.             into account any known anomalies
  686.             in the chip."
  687.             ::= { dot3StatsEntry 17 }
  688.  
  689.        -- the Ethernet-like Collision Statistics group
  690.  
  691.        -- Implementation of this group is optional; it is appropriate
  692.        -- for all systems which have the necessary metering
  693.  
  694.        dot3CollTable  OBJECT-TYPE
  695.             SYNTAX    SEQUENCE OF Dot3CollEntry
  696.             ACCESS    not-accessible
  697.             STATUS    mandatory
  698.             DESCRIPTION
  699.             "A collection of collision histograms for a
  700.             particular set of interfaces."
  701.             ::= { dot3 5 }
  702.  
  703.  
  704.        dot3CollEntry  OBJECT-TYPE
  705.             SYNTAX    Dot3CollEntry
  706.             ACCESS    not-accessible
  707.             STATUS    mandatory
  708.             DESCRIPTION
  709.             "A cell in the histogram of per-frame
  710.             collisions for a particular interface.  An
  711.             instance of this object represents the
  712.             frequency of individual MAC frames for which
  713.             the transmission (successful or otherwise) on a
  714.             particular interface is accompanied by a
  715.             particular number of media collisions."
  716.             INDEX     { ifIndex, dot3CollCount }
  717.             ::= { dot3CollTable 1 }
  718.  
  719.        Dot3CollEntry ::= SEQUENCE {
  720.             dot3CollCount        INTEGER,
  721.             dot3CollFrequencies  Counter
  722.        }
  723.  
  724.        -- { dot3CollEntry 1 } is no longer in use
  725.  
  726.        dot3CollCount  OBJECT-TYPE
  727.  
  728.  
  729.  
  730. Kastenholz                                                     [Page 13]
  731.  
  732. RFC 1643                   Ethernet-Like MIB                   July 1994
  733.  
  734.  
  735.             SYNTAX    INTEGER (1..16)
  736.             ACCESS    not-accessible
  737.             STATUS    mandatory
  738.             DESCRIPTION
  739.             "The number of per-frame media collisions for
  740.             which a particular collision histogram cell
  741.             represents the frequency on a particular
  742.             interface."
  743.             ::= { dot3CollEntry 2 }
  744.  
  745.  
  746.        dot3CollFrequencies   OBJECT-TYPE
  747.             SYNTAX    Counter
  748.             ACCESS    read-only
  749.             STATUS    mandatory
  750.             DESCRIPTION
  751.             "A count of individual MAC frames for which the
  752.             transmission (successful or otherwise) on a
  753.             particular interface occurs after the
  754.             frame has experienced exactly the number
  755.             of collisions in the associated
  756.             dot3CollCount object.
  757.  
  758.             For example, a frame which is transmitted
  759.             on interface 77 after experiencing
  760.             exactly 4 collisions would be indicated
  761.             by incrementing only dot3CollFrequencies.77.4.
  762.             No other instance of dot3CollFrequencies would
  763.             be incremented in this example."
  764.             ::= { dot3CollEntry 3 }
  765.  
  766.        --  802.3 Tests
  767.  
  768.        dot3Tests   OBJECT IDENTIFIER ::= { dot3 6 }
  769.  
  770.        dot3Errors  OBJECT IDENTIFIER ::= { dot3 7 }
  771.  
  772.  
  773.        --  TDR Test
  774.  
  775.        -- The Time-Domain Reflectometry (TDR) test is specific
  776.        -- to ethernet-like interfaces with the exception of
  777.        -- 10BaseT and 10BaseF. The TDR value may be useful
  778.        -- in determining the approximate distance to a cable fault.
  779.        -- It is advisable to repeat this test to check for a
  780.        -- consistent resulting TDR value, to verify that there
  781.        -- is a fault.
  782.  
  783.  
  784.  
  785.  
  786. Kastenholz                                                     [Page 14]
  787.  
  788. RFC 1643                   Ethernet-Like MIB                   July 1994
  789.  
  790.  
  791.        dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 }
  792.  
  793.        -- A TDR test returns as its result the time interval,
  794.        -- measured in 10 MHz ticks or 100 nsec units, between
  795.        -- the start of TDR test transmission and the subsequent
  796.        -- detection of a collision or deassertion of carrier.  On
  797.        -- successful completion of a TDR test, the result is
  798.        -- stored as the value of the appropriate instance of the
  799.        -- MIB object dot3TestTdrValue, and the OBJECT IDENTIFIER
  800.        -- of that instanceis stored in the corresponding instance
  801.        -- of ifExtnsTestCode (thereby indicating where the
  802.        -- result has been stored).
  803.  
  804.  
  805.        -- Loopback Test
  806.  
  807.        -- Another test is the full-duplex loopback test.
  808.        -- This test configures the MAC chip and executes
  809.        -- an internal loopback test of memory, data paths,
  810.        -- and the MAC chip logic.  This loopback test can
  811.        -- only be executed if the interface is offline.
  812.        -- Once the test has completed, the MAC chip should
  813.        -- be reinitialized for network operation, but it
  814.        -- should remain offline.
  815.  
  816.        dot3TestLoopBack OBJECT IDENTIFIER ::= { dot3Tests 2 }
  817.  
  818.        -- If an error occurs during a test, the object
  819.        -- ifTestResult (defined in RFC1573) will be set
  820.        -- to failed(7).  The following two OBJECT
  821.        -- IDENTIFIERs may be used to provided more
  822.        -- information as values for ifTestCode.
  823.  
  824.                 -- couldn't initialize MAC chip for test
  825.        dot3ErrorInitError     OBJECT IDENTIFIER ::= { dot3Errors 1 }
  826.  
  827.                 -- expected data not received (or not
  828.                 -- received correctly) in loopback test
  829.        dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 }
  830.  
  831.        -- RFC1573 does away with the interface chipset object.
  832.        -- The following OBJECT IDENTIFIER definitions are
  833.        -- retained for purposes of backwards compatibility
  834.        -- with pre-RFC1573 systems.
  835.        --  802.3 Hardware Chipsets
  836.  
  837.        -- The object ifExtnsChipSet is provided in RFC1229 to
  838.        -- identify the MAC hardware used to communcate on an
  839.  
  840.  
  841.  
  842. Kastenholz                                                     [Page 15]
  843.  
  844. RFC 1643                   Ethernet-Like MIB                   July 1994
  845.  
  846.  
  847.        -- interface.  The following hardware chipsets are
  848.        -- provided for 802.3:
  849.  
  850.        dot3ChipSets          OBJECT IDENTIFIER ::= { dot3 8 }
  851.        dot3ChipSetAMD        OBJECT IDENTIFIER ::= { dot3ChipSets 1 }
  852.        dot3ChipSetAMD7990    OBJECT IDENTIFIER ::= { dot3ChipSetAMD 1 }
  853.        dot3ChipSetAMD79900   OBJECT IDENTIFIER ::= { dot3ChipSetAMD 2 }
  854.        dot3ChipSetAMD79C940  OBJECT IDENTIFIER ::= { dot3ChipSetAMD 3 }
  855.  
  856.        dot3ChipSetIntel      OBJECT IDENTIFIER ::= { dot3ChipSets 2 }
  857.        dot3ChipSetIntel82586 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 1 }
  858.        dot3ChipSetIntel82596 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 2 }
  859.  
  860.        dot3ChipSetSeeq       OBJECT IDENTIFIER ::= { dot3ChipSets 3 }
  861.        dot3ChipSetSeeq8003   OBJECT IDENTIFIER ::= { dot3ChipSetSeeq 1 }
  862.  
  863.        dot3ChipSetNational      OBJECT IDENTIFIER ::= { dot3ChipSets 4 }
  864.        dot3ChipSetNational8390  OBJECT IDENTIFIER ::=
  865.                                   { dot3ChipSetNational 1 }
  866.        dot3ChipSetNationalSonic OBJECT IDENTIFIER ::=
  867.                                   { dot3ChipSetNational 2 }
  868.  
  869.        dot3ChipSetFujitsu       OBJECT IDENTIFIER ::= { dot3ChipSets 5 }
  870.        dot3ChipSetFujitsu86950  OBJECT IDENTIFIER ::=
  871.                                   { dot3ChipSetFujitsu 1 }
  872.  
  873.        dot3ChipSetDigital       OBJECT IDENTIFIER ::= { dot3ChipSets 6 }
  874.        dot3ChipSetDigitalDC21040  OBJECT IDENTIFIER ::=
  875.                                   { dot3ChipSetDigital 1 }
  876.  
  877.        -- For those chipsets not represented above, OBJECT IDENTIFIER
  878.        -- assignment is required in other documentation, e.g., assignment
  879.        -- within that part of the registration tree delegated to
  880.        -- individual enterprises (see RFC1155).
  881.  
  882.    END
  883.  
  884. 5.  Acknowledgements
  885.  
  886.    This document was produced by the Ethernet MIB Working Group.
  887.  
  888.    This document is based on the Proposed Standard Ethernet MIB, RFC
  889.    1284 [14], of which Jihn Cook of Chipcom was the editor.  The
  890.    Ethernet MIB Working Group gathered implementation experience of the
  891.    variables specified in RFC 1284 and used that information to develop
  892.    this revised MIB.
  893.  
  894.    RFC 1284, in turn, is based on a document written by Frank Kastenholz
  895.  
  896.  
  897.  
  898. Kastenholz                                                     [Page 16]
  899.  
  900. RFC 1643                   Ethernet-Like MIB                   July 1994
  901.  
  902.  
  903.    of Interlan entitled IEEE 802.3 Layer Management Draft M compatible
  904.    MIB for TCP/IP Networks [10].  This document has been modestly
  905.    reworked, initially by the SNMP Working Group, and then by the
  906.    Transmission Working Group, to reflect the current conventions for
  907.    defining objects for MIB interfaces.  James Davin, of the MIT
  908.    Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN
  909.    Systems, contributed to later drafts of this memo. Marshall Rose of
  910.    Performance Systems International, Inc. converted the document into
  911.    its current concise format. Anil Rijsinghani of DEC contributed text
  912.    that more adequately describes the TDR test.  Thanks to Frank
  913.    Kastenholz of Interlan and Louis Steinberg of IBM for their
  914.    experimentation.
  915.  
  916. 6.  References
  917.  
  918.    [1] Cerf, V., "IAB Recommendations for the Development of Internet
  919.        Network Management Standards", RFC 1052, NRI, April 1988.
  920.  
  921.    [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
  922.        Group", RFC 1109, NRI, August 1989.
  923.  
  924.    [3] Rose M., and K. McCloghrie, "Structure and Identification of
  925.        Management Information for TCP/IP-based internets", STD 16, RFC
  926.        1155, Performance Systems International, Hughes LAN Systems, May
  927.        1990.
  928.  
  929.    [4] McCloghrie K., and M. Rose, "Management Information Base for
  930.        Network Management of TCP/IP-based internets", RFC 1156, Hughes
  931.        LAN Systems, Performance Systems International, May 1990.
  932.  
  933.    [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
  934.        Network Management Protocol", STD 15, RFC 1157, SNMP Research,
  935.        Performance Systems International, Performance Systems
  936.        International, MIT Laboratory for Computer Science, May 1990.
  937.  
  938.    [6] McCloghrie K., and M. Rose, Editors, "Management Information Base
  939.        for Network Management of TCP/IP-based internets", STD 17, RFC
  940.        1213, Performance Systems International, March 1991.
  941.  
  942.    [7] Information processing systems - Open Systems Interconnection -
  943.        Specification of Abstract Syntax Notation One (ASN.1),
  944.        International Organization for Standardization, International
  945.        Standard 8824, December 1987.
  946.  
  947.    [8] Information processing systems - Open Systems Interconnection -
  948.        Specification of Basic Encoding Rules for Abstract Notation One
  949.        (ASN.1), International Organization for Standardization,
  950.        International Standard 8825, December 1987.
  951.  
  952.  
  953.  
  954. Kastenholz                                                     [Page 17]
  955.  
  956. RFC 1643                   Ethernet-Like MIB                   July 1994
  957.  
  958.  
  959.    [9] IEEE, "IEEE 802.3 Layer Management", November 1988.
  960.  
  961.   [10] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible MIB
  962.        for TCP/IP Networks", electronic mail message to mib-
  963.        wg@nnsc.nsf.net, 9 June 1989.
  964.  
  965.   [11] McCloghrie, K., Editor, "Extensions to the Generic-Interface
  966.        MIB", RFC 1229, Hughes LAN Systems, Inc., May 1991.
  967.  
  968.   [12] IEEE, "Carrier Sense Multiple Access with Collision Detection
  969.        (CSMA/CD) Access Method and Physical Layer Specifications",
  970.        ANSI/IEEE Std 802.3-1985.
  971.  
  972.   [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
  973.        RFC 1212, Performance Systems International, Hughes LAN Systems,
  974.        March 1991.
  975.  
  976.   [14] Cook, J., Editor, "Definitions of Managed Objects for Ethernet-
  977.        Like Interface Types", RFC 1284, Chipcom Corporation, December
  978.        1991.
  979.  
  980.   [15] Kastenholz, F., "Definitions of Managed Objects for the
  981.        Ethernet-like Interface Types", RFC 1398, FTP Software, Inc.,
  982.        January 1993.
  983.  
  984.   [16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
  985.        of Management Information for version 2 of the Simple Network
  986.        Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
  987.        Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  988.        University, April 1993.
  989.  
  990.   [17] Galvin, J., and K. McCloghrie, "Administrative Model for version
  991.        2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
  992.        Trusted Information Systems, Hughes LAN Systems, April 1993.
  993.  
  994.   [18] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
  995.        Operations for version 2 of the Simple Network Management
  996.        Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
  997.        Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  998.        University, April 1993.
  999.  
  1000.   [19] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces
  1001.        Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software,
  1002.        January 1994.
  1003.  
  1004.   [20] Kastenholz, F., "Definitions of Managed Objects for the
  1005.        Ethernet-like Interface Types", STD 50, RFC 1623, FTP Software,
  1006.        Inc., May 1994.
  1007.  
  1008.  
  1009.  
  1010. Kastenholz                                                     [Page 18]
  1011.  
  1012. RFC 1643                   Ethernet-Like MIB                   July 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.