idnits 2.17.1 draft-ietf-hubmib-etherif-mib-v2-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 47 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document obsoletes RFC2358, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 560 has weird spacing: '...issions dot...' == Line 566 has weird spacing: '...cvError dot3S...' == Line 590 has weird spacing: '...pported dot3...' == Line 595 has weird spacing: '...smitted dot3O...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1999) is 9113 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2571 (ref. '1') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') ** Obsolete normative reference: RFC 1906 (ref. '10') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (ref. '11') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (ref. '12') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (ref. '14') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '15') (Obsoleted by RFC 3415) -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 1284 (ref. '18') (Obsoleted by RFC 1398) ** Downref: Normative reference to an Informational RFC: RFC 1369 (ref. '19') ** Obsolete normative reference: RFC 1398 (ref. '20') (Obsoleted by RFC 1623) ** Obsolete normative reference: RFC 1643 (ref. '21') (Obsoleted by RFC 3638) ** Obsolete normative reference: RFC 1650 (ref. '22') (Obsoleted by RFC 2358) ** Obsolete normative reference: RFC 2358 (ref. '23') (Obsoleted by RFC 2665) ** Obsolete normative reference: RFC 2233 (ref. '25') (Obsoleted by RFC 2863) == Outdated reference: A later version (-04) exists of draft-ietf-hubmib-mau-mib-v2-02 == Outdated reference: A later version (-02) exists of draft-ietf-hubmib-ether-chipsets-00 ** Downref: Normative reference to an Informational draft: draft-ietf-hubmib-ether-chipsets (ref. '28') Summary: 24 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Hub MIB Working Group J. Flick 2 INTERNET DRAFT Hewlett-Packard Company 3 J. Johnson 4 RedBack Networks 5 May 1999 7 Definitions of Managed Objects for 8 the Ethernet-like Interface Types 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 Abstract 37 This memo defines a portion of the Management Information Base (MIB) 38 for use with network management protocols in the Internet community. 39 This memo obsoletes RFC 2358 ''Definitions of Managed Objects for the 40 Ethernet-like Interface Types''. This memo extends that 41 specification by including management information useful for the 42 management of 1000 Mb/s and full-duplex Ethernet interfaces. 44 Ethernet technology, as defined by the 802.3 Working Group of the 45 IEEE, continues to evolve, with scalable increases in speed, new 46 types of cabling and interfaces, and new features. This evolution 47 may require changes in the managed objects in order to reflect this 48 new functionality. This document, as with other documents issued by 49 this working group, reflects a certain stage in the evolution of 50 Ethernet technology. In the future, this document might be revised, 51 or new documents might be issued by the Ethernet Interfaces and Hub 52 MIB Working Group, in order to reflect the evolution of Ethernet 53 technology. 55 Distribution of this memo is unlimited. Please forward comments to 56 hubmib@hprnd.rose.hp.com. 58 Table of Contents 60 1. Introduction ................................................ 2 61 2. The SNMP Management Framework .............................. 3 62 3. Overview ................................................... 4 63 3.1. Relation to MIB-2 ........................................ 4 64 3.2. Relation to the Interfaces MIB ........................... 5 65 3.2.1. Layering Model ......................................... 5 66 3.2.2. Virtual Circuits ....................................... 5 67 3.2.3. ifTestTable ............................................ 5 68 3.2.4. ifRcvAddressTable ...................................... 6 69 3.2.5. ifPhysAddress .......................................... 6 70 3.2.6. ifType ................................................. 7 71 3.2.7. Specific Interface MIB Objects ......................... 7 72 3.3. Relation to the 802.3 MAU MIB ............................ 11 73 3.4. dot3StatsEtherChipSet .................................... 12 74 3.5. Mapping of IEEE 802.3 Managed Objects .................... 12 75 4. Definitions ................................................ 16 76 5. Intellectual Property ...................................... 39 77 6. Acknowledgements ........................................... 40 78 7. References ................................................. 41 79 8. Security Considerations .................................... 44 80 9. Author's Addresses ......................................... 45 81 A. Change Log ................................................. 45 82 A.1. Changes since RFC 2358 ................................... 45 83 A.2. Changes between RFC 1650 and RFC 2358 .................... 46 84 B. Full Copyright Statement ................................... 47 86 1. Introduction 88 This memo defines a portion of the Management Information Base (MIB) 89 for use with network management protocols in the Internet community. 90 In particular, it defines objects for managing Ethernet-like 91 interfaces. 93 This memo also includes a MIB module. This MIB module extends the 94 list of managed objects specified in the earlier version of this MIB: 95 RFC 2358 [23]. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [26]. 101 2. The SNMP Management Framework 103 The SNMP Management Framework presently consists of five major 104 components: 106 o An overall architecture, described in RFC 2571 [1]. 108 o Mechanisms for describing and naming objects and events for the 109 purpose of management. The first version of this Structure of 110 Management Information (SMI) is called SMIv1 and described in 111 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, 112 called SMIv2, is described in RFC 2578 [5], RFC 2579 [6] and RFC 113 2580 [7]. 115 o Message protocols for transferring management information. The 116 first version of the SNMP message protocol is called SNMPv1 and 117 described in RFC 1157 [8]. A second version of the SNMP message 118 protocol, which is not an Internet standards track protocol, is 119 called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 120 The third version of the message protocol is called SNMPv3 and 121 described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. 123 o Protocol operations for accessing management information. The 124 first set of protocol operations and associated PDU formats is 125 described in RFC 1157 [8]. A second set of protocol operations 126 and associated PDU formats is described in RFC 1905 [13]. 128 o A set of fundamental applications described in RFC 2573 [14] and 129 the view-based access control mechanism described in RFC 2575 130 [15]. 132 Managed objects are accessed via a virtual information store, termed 133 the Management Information Base or MIB. Objects in the MIB are 134 defined using the mechanisms defined in the SMI. 136 This memo specifies a MIB module that is compliant to the SMIv2. A 137 MIB conforming to the SMIv1 can be produced through the appropriate 138 translations. The resulting translated MIB must be semantically 139 equivalent, except where objects or events are omitted because no 140 translation is possible (use of Counter64). Some machine readable 141 information in SMIv2 will be converted into textual descriptions in 142 SMIv1 during the translation process. However, this loss of machine 143 readable information is not considered to change the semantics of the 144 MIB. 146 3. Overview 148 Instances of these object types represent attributes of an interface 149 to an ethernet-like communications medium. At present, ethernet-like 150 media are identified by the following values of the ifType object in 151 the Interfaces MIB [25]: 153 ethernetCsmacd(6) 154 iso88023Csmacd(7) 155 starLan(11) 157 The definitions presented here are based on Section 30, "10 Mb/s, 100 158 Mb/s and 1000 Mb/s Management", and Annex 30A, "GDMO Specification 159 for 802.3 managed object classes" of IEEE Std. 802.3, 1998 Edition 160 [16], as originally interpreted by Frank Kastenholz then of Interlan 161 in [17]. Implementors of these MIB objects should note that IEEE 162 Std. 802.3 [16] explicitly describes (in the form of Pascal 163 pseudocode) when, where, and how various MAC attributes are measured. 164 The IEEE document also describes the effects of MAC actions that may 165 be invoked by manipulating instances of the MIB objects defined here. 167 To the extent that some of the attributes defined in [16] are 168 represented by previously defined objects in MIB-2 [24] or in the 169 Interfaces MIB [25], such attributes are not redundantly represented 170 by objects defined in this memo. Among the attributes represented by 171 objects defined in other memos are the number of octets transmitted 172 or received on a particular interface, the number of frames 173 transmitted or received on a particular interface, the promiscuous 174 status of an interface, the MAC address of an interface, and 175 multicast information associated with an interface. 177 3.1. Relation to MIB-2 179 This section applies only when this MIB is used in conjunction with 180 the "old" (RFC 1213) [24] interface group. 182 The relationship between an ethernet-like interface and an interface 183 in the context of MIB-2 is one-to-one. As such, the value of an 184 ifIndex object instance can be directly used to identify 185 corresponding instances of the objects defined herein. 187 For agents which implement the (now deprecated) ifSpecific object, an 188 instance of that object that is associated with an ethernet-like 189 interface has the OBJECT IDENTIFIER value: 191 dot3 OBJECT IDENTIFER ::= { transmission 7 } 193 3.2. Relation to the Interfaces MIB 195 The Interface MIB [25] requires that any MIB which is an adjunct of 196 the Interface MIB clarify specific areas within the Interface MIB. 197 These areas were intentionally left vague in the Interface MIB to 198 avoid over constraining the MIB, thereby precluding management of 199 certain media-types. 201 Section 3.3 of [25] enumerates several areas which a media-specific 202 MIB must clarify. Each of these areas is addressed in a following 203 subsection. The implementor is referred to [25] in order to 204 understand the general intent of these areas. 206 3.2.1. Layering Model 208 This MIB does not provide for layering. There are no sublayers. 210 EDITOR'S NOTE: 212 One could foresee the development of an 802.2 and enet-transceiver 213 MIB. They could be higher and lower sublayers, respectively. All 214 that THIS document should do is allude to the possibilities and urge 215 the implementor to be aware of the possibility and that they may have 216 requirements which supersede the requirements in this document. 218 3.2.2. Virtual Circuits 220 This medium does not support virtual circuits and this area is not 221 applicable to this MIB. 223 3.2.3. ifTestTable 225 This MIB defines two tests for media which are instrumented with this 226 MIB; TDR and Loopback. Implementation of these tests is not 227 required. Many common interface chips do not support one or both of 228 these tests. 230 These two tests are provided as a convenience, allowing a common 231 method to invoke the test. 233 Standard MIBs do not include objects in which to return the results 234 of the TDR test. Any needed objects MUST be provided in the vendor 235 specific MIB. 237 Note that the ifTestTable is now deprecated. Work is underway to 238 define a replacement MIB for system and interface testing. It is 239 expected that the tests defined in this document will be usable in 240 this replacement MIB. 242 3.2.4. ifRcvAddressTable 244 This table contains all IEEE 802.3 addresses, unicast, multicast, and 245 broadcast, for which this interface will receive packets and forward 246 them up to a higher layer entity for local consumption. The format 247 of the address, contained in ifRcvAddressAddress, is the same as for 248 ifPhysAddress. 250 In the event that the interface is part of a MAC bridge, this table 251 does not include unicast addresses which are accepted for possible 252 forwarding out some other port. This table is explicitly not 253 intended to provide a bridge address filtering mechanism. 255 3.2.5. ifPhysAddress 257 This object contains the IEEE 802.3 address which is placed in the 258 source-address field of any Ethernet, Starlan, or IEEE 802.3 frames 259 that originate at this interface. Usually this will be kept in ROM 260 on the interface hardware. Some systems may set this address via 261 software. 263 In a system where there are several such addresses the designer has a 264 tougher choice. The address chosen should be the one most likely to 265 be of use to network management (e.g. the address placed in ARP 266 responses for systems which are primarily IP systems). 268 If the designer truly can not chose, use of the factory- provided ROM 269 address is suggested. 271 If the address can not be determined, an octet string of zero length 272 should be returned. 274 The address is stored in binary in this object. The address is 275 stored in "canonical" bit order, that is, the Group Bit is positioned 276 as the low-order bit of the first octet. Thus, the first byte of a 277 multicast address would have the bit 0x01 set. 279 3.2.6. ifType 281 This MIB applies to interfaces which have any of the following ifType 282 values: 284 ethernetCsmacd(6) 285 iso88023Csmacd(7) 286 starLan(11) 288 It is RECOMMENDED that all Ethernet-like interfaces use an ifType of 289 ethernetCsmacd(6) regardless of the speed that the interface is 290 running or the link-layer encapsulation in use. iso88023Csmacd(7) 291 and starLan(11) are supported for backwards compatability. 293 There are three other interface types defined in the IANAifType-MIB 294 for Ethernet. They are fastEther(62), fastEtherFX(69), and 295 gigabitEthernet(117). This document takes the position that an 296 Ethernet is an Ethernet, and Ethernet interfaces SHOULD always have 297 the same value of ifType. Information on the particular flavor of 298 Ethernet that an interface is running is available from ifSpeed in 299 the Interfaces MIB, and ifMauType in the 802.3 MAU MIB. An 300 Ethernet-like interface SHOULD NOT use the fastEther(62), 301 fastEtherFX(69), or gigabitEthernet(117) ifTypes. 303 Interfaces with any of the supported ifType values map to the 304 EtherLike-MIB in the same manner. There are no implementation 305 differences. 307 3.2.7. Specific Interface MIB Objects 309 The following table provides specific implementation guidelines for 310 applying the interface group objects to ethernet-like media. 312 Object Guidelines 314 ifIndex Each ethernet-like interface is 315 represented by an ifEntry. The 316 dot3StatsTable in this MIB module is 317 indexed by dot3StatsIndex. The interface 318 identified by a particular value of 319 dot3StatsIndex is the same interface as 320 identified by the same value of ifIndex. 322 ifDescr Refer to [25]. 324 ifType Refer to section 3.2.6. 326 ifMtu 1500 octets. NOTE: This is the MTU as 327 seen by the MAC client. When a higher 328 layer protocol, like IP, is running over 329 Ethernet, this is the MTU that will be 330 seen by that higher layer protocol. 331 However, when using the IEEE 802.2 LLC 332 protocol, higher layer protocols will 333 see a different MTU. In particular, an 334 LLC type 1 client protocol will see 335 an MTU of 1497 octets, and a protocol 336 running over SNAP will see an MTU of 337 1492 octets. 339 ifSpeed The current operational speed of the 340 interface in bits per second. For 341 current ethernet-like interfaces, this 342 will be equal to 1,000,000 (1 million), 343 10,000,000 (10 million), 100,000,000 344 (100 million), or 1,000,000,000 (1 345 billion). If the interface implements 346 auto-negotiation, auto-negotiation is 347 enabled for this interface, and the 348 interface has not yet negotiated to an 349 operational speed, this object SHOULD 350 reflect the maximum speed supported by 351 the interface. Note that this object 352 MUST NOT indicate a doubled value when 353 operating in full-duplex mode. It MUST 354 indicate the correct line speed 355 regardless of the current duplex mode. 356 The duplex mode of the interface may 357 be determined by examining either the 358 dot3StatsDuplexStatus object in this 359 MIBmodule, or the ifMauType object in 360 the 802.3 MAU MIB. 362 ifPhysAddress Refer to section 3.2.5. 364 ifAdminStatus Write access is not required. Support 365 for 'testing' is not required. 367 ifOperStatus The operational state of the interface. 368 Support for 'testing' is not required. 369 The value 'dormant' has no meaning for 370 an ethernet-like interface. 372 ifLastChange Refer to [25]. 374 ifInOctets The number of octets in valid MAC frames 375 received on this interface, including 376 the MAC header and FCS. This does 377 include the number of octets in valid 378 MAC Control frames received on this 379 interface. 381 ifInUcastPkts Refer to [25]. Note that this does not 382 include MAC Control frames, since MAC 383 Control frames are consumed by the 384 interface layer and are not passed to 385 any higher layer protocol. 387 ifInDiscards Refer to [25]. 389 ifInErrors The sum for this interface of 390 dot3StatsAlignmentErrors, 391 dot3StatsFCSErrors, 392 dot3StatsFrameTooLongs, 393 dot3StatsInternalMacReceiveErrors and 394 dot3StatsSymbolErrors. 396 ifInUnknownProtos Refer to [25]. 398 ifOutOctets The number of octets transmitted in 399 valid MAC frames on this interface, 400 including the MAC header and FCS. This 401 does include the number of octets in 402 valid MAC Control frames transmitted on 403 this interface. 405 ifOutUcastPkts Refer to [25]. Note that this does not 406 include MAC Control frames, since MAC 407 Control frames are generated by the 408 interface layer, and are not passed from 409 any higher layer protocol. 411 ifOutDiscards Refer to [25]. 413 ifOutErrors The sum for this interface of: 414 dot3StatsSQETestErrors, 415 dot3StatsLateCollisions, 416 dot3StatsExcessiveCollisions, 417 dot3StatsInternalMacTransmitErrors and 418 dot3StatsCarrierSenseErrors. 420 ifName Locally-significant textual name for the 421 interface (e.g. lan0). 423 ifInMulticastPkts Refer to [25]. Note that this does not 424 include MAC Control frames, since MAC 425 Control frames are consumed by the 426 interface layer and are not passed to 427 any higher layer protocol. 429 ifInBroadcastPkts Refer to [25]. Note that this does not 430 include MAC Control frames, since MAC 431 Control frames are generated by the 432 interface layer, and are not passed from 433 any higher layer protocol. 435 ifOutMulticastPkts Refer to [25]. Note that this does not 436 include MAC Control frames, since MAC 437 Control frames are consumed by the 438 interface layer and are not passed to 439 any higher layer protocol. 441 ifOutBroadcastPkts Refer to [25]. Note that this does not 442 include MAC Control frames, since MAC 443 Control frames are generated by the 444 interface layer, and are not passed from 445 any higher layer protocol. 447 ifHCInOctets 64-bit versions of counters. Required 448 ifHCOutOctets for ethernet-like interfaces that are 449 capable of operating at 20Mbit/sec or 450 faster, even if the interface is 451 currently operating at less than 452 20Mbit/sec. 454 ifHCInUcastPkts 64-bit versions of packet counters. 455 ifHCInMulticastPkts Required for ethernet-like interfaces 456 ifHCInBroadcastPkts that are capable of operating at 457 ifHCOutUcastPkts 640Mbit/sec or faster, even if the 458 ifHCOutMulticastPkts interface is currently operating at 459 ifHCOutBroadcastPkts less than 640Mbit/sec. 461 ifLinkUpDownTrapEnable Refer to [25]. Default is 'enabled' 463 ifHighSpeed The current operational speed of the 464 interface in millions of bits per 465 second. For current ethernet-like 466 interfaces, this will be equal to 1, 10, 467 100, or 1,000. If the interface 468 implements auto-negotiation, 469 auto-negotiation is enabled for this 470 interface, and the interface has not yet 471 negotiated to an operational speed, this 472 object SHOULD reflect the maximum speed 473 supported by the interface. Note that 474 this object MUST NOT indicate a doubled 475 value when operating in full-duplex 476 mode. It MUST indicate the correct line 477 speed regardless of the current duplex 478 mode. The duplex mode of the interface 479 may be determined by examining either 480 the dot3StatsDuplexStatus object in this 481 MIB module, or the ifMauType object in 482 the 802.3 MAU MIB. 484 ifPromiscuousMode Refer to [25]. 486 ifConnectorPresent This will normally be 'true'. 488 ifAlias Refer to [25]. 490 ifCounterDiscontinuityTime Refer to [25]. Note that a 491 discontinuity in the Interface MIB 492 counters may also indicate a 493 discontinuity in some or all of the 494 counters in this MIB that are associated 495 with that interface. 497 ifStackHigherLayer Refer to section 3.2.1. 498 ifStackLowerLayer 499 ifStackStatus 501 ifRcvAddressAddress Refer to section 3.2.4. 502 ifRcvAddressStatus 503 ifRcvAddressType 505 3.3. Relation to the 802.3 MAU MIB 507 Support for the mauModIfCompl2 compliance statement of the MAU-MIB 508 [27] is REQUIRED for Ethernet-like interfaces. This MIB is needed in 509 order to allow applications to determine the current MAU type in use 510 by the interface, and to control autonegotiation and duplex mode for 511 the interface. Implementing this MIB module without implementing the 512 MAU-MIB would leave applications with no standard way to determine 513 the media type in use, and no standard way to control the duplex mode 514 of the interface. 516 3.4. dot3StatsEtherChipSet 518 This document defines an object called dot3StatsEtherChipSet, which 519 is used to identify the MAC hardware used to communicate on an 520 interface. Previous versions of this document contained a number of 521 OID assignments for some existing Ethernet chipsets. Maintaining 522 that list as part of this document has proven to be problematic, so 523 the OID assignments contained in prevous versions of this document 524 have now been moved to a separate document [28]. 526 The dot3StatsEtherChipSet object has now been deprecated. 527 Implementation feedback indicates that this object is much more 528 useful in theory than in practice. The object's utility in debugging 529 network problems in the field appears to be limited. In those cases 530 where it may be useful, it is not sufficient, since it identifies 531 only the MAC chip, and not the PHY, PMD, or driver. The 532 administrative overhead involved in maintaining a central registry of 533 chipset OIDs cannot be justified for an object whose usefulness is 534 questionable at best. 536 Implementations which continue to support this object for the purpose 537 of backwards compatability may continue to use the values defined in 538 [28]. For chipsets not listed in [28], implementors should assign 539 OBJECT IDENTIFIERS within that part of the registration tree 540 delegated to individual enterprises. 542 3.5. Mapping of IEEE 802.3 Managed Objects 544 IEEE 802.3 Managed Object Corresponding SNMP Object 546 oMacEntity 547 .aMACID dot3StatsIndex or 548 IF-MIB - ifIndex 549 .aFramesTransmittedOK IF-MIB - ifOutUCastPkts + 550 ifOutMulticastPkts + 551 ifOutBroadcastPkts* 552 .aSingleCollisionFrames dot3StatsSingleCollisionFrames 553 .aMultipleCollisionFrames dot3StatsMultipleCollisionFrames 554 .aFramesReceivedOK IF-MIB - ifInUcastPkts + 555 ifInMulticastPkts + 556 ifInBroadcastPkts* 557 .aFrameCheckSequenceErrors dot3StatsFCSErrors 558 .aAlignmentErrors dot3StatsAlignmentErrors 559 .aOctetsTransmittedOK IF-MIB - ifOutOctets* 560 .aFramesWithDeferredXmissions dot3StatsDeferredTransmissions 561 .aLateCollisions dot3StatsLateCollisions 562 .aFramesAbortedDueToXSColls dot3StatsExcessiveCollisions 563 .aFramesLostDueToIntMACXmitError dot3StatsInternalMacTransmitErrors 564 .aCarrierSenseErrors dot3StatsCarrierSenseErrors 565 .aOctetsReceivedOK IF-MIB - ifInOctets* 566 .aFramesLostDueToIntMACRcvError dot3StatsInternalMacReceiveErrors 567 .aPromiscuousStatus IF-MIB - ifPromiscuousMode 568 .aReadMulticastAddressList IF-MIB - ifRcvAddressTable 569 .aMulticastFramesXmittedOK IF-MIB - ifOutMulticastPkts* 570 .aBroadcastFramesXmittedOK IF-MIB - ifOutBroadcastPkts* 571 .aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts* 572 .aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts* 573 .aFrameTooLongErrors dot3StatsFrameTooLongs 574 .aReadWriteMACAddress IF-MIB - ifPhysAddress 575 .aCollisionFrames dot3CollFrequencies 576 .aDuplexStatus dot3StatsDuplexStatus 577 .acAddGroupAddress IF-MIB - ifRcvAddressTable 578 .acDeleteGroupAddress IF-MIB - ifRcvAddressTable 579 .acExecuteSelfTest dot3TestLoopBack 581 oPHYEntity 582 .aPHYID dot3StatsIndex or 583 IF-MIB - ifIndex 584 .aSQETestErrors dot3StatsSQETestErrors 585 .aSymbolErrorDuringCarrier dot3StatsSymbolErrors 587 oMACControlEntity 588 .aMACControlID dot3StatsIndex or 589 IF-MIB - ifIndex 590 .aMACControlFunctionsSupported dot3ControlFunctionsSupported and 591 dot3ControlFunctionsEnabled 592 .aUnsupportedOpcodesReceived dot3ControlInUnknownOpcodes 594 oPAUSEEntity 595 .aPAUSEMACCtrlFramesTransmitted dot3OutPauseFrames 596 .aPAUSEMACCtrlFramesReceived dot3InPauseFrames 598 * Note that the octet counters in IF-MIB do not exactly match the 599 definition of the octet counters in IEEE 802.3. aOctetsTransmittedOK 600 and aOctetsReceivedOK count only the octets in the clientData and Pad 601 fields, whereas ifInOctets and ifOutOctets include the entire MAC 602 frame, including MAC header and FCS. However, the IF-MIB counters 603 can be derived from the IEEE 802.3 counters as follows: 605 ifInOctets = aOctetsReceivedOK + (18 * aFramesReceivedOK) 606 ifOutOctets = aOctetsTransmittedOK + (18 * aFramesTransmittedOK) 608 Also note that the packet counters in the IF-MIB do not exactly match 609 the definition of the frame counters in IEEE 802.3. 610 aFramesTransmittedOK counts the number of frames successfully 611 transmitted on the interface, whereas ifOutUcastPkts, 612 ifOutMulticastPkts and ifOutBroadcastPkts count the number of 613 transmit requests made from a higher layer, whether or not the 614 transmit attempt was successful. This means that packets counted by 615 ifOutErrors or ifOutDiscards are also be counted by ifOut*castPkts, 616 but are not be counted by aFramesTransmittedOK. This also means 617 that, since MAC Control frames are generated by a sublayer internal 618 to the interface layer rather than by a higher layer, they are not 619 counted by ifOut*castPkts, but are counted by aFramesTransmittedOK. 621 Similarly, aFramesReceivedOK counts the number of frames received 622 successfully by the interface, whether or not they are passed to a 623 higher layer, whereas ifInUcastPkts, ifInMulticastPkts and 624 ifInBroadcastPkts count only the number of packets passed to a higher 625 layer. This means that packets counted by ifInDiscards or 626 ifInUnknownProtos are also counted by aFramesReceivedOK, but are not 627 counted by ifIn*castPkts. This also menas that, since MAC Control 628 frames are consumed by a sublayer internal to the interface layer and 629 not passed to a higher layer, they are not counted by ifIn*castPkts, 630 but are counted by aFramesReceivedOK. 632 Another difference to keep in mind between the IF-MIB counters and 633 IEEE 802.3 counters is that in the IEEE 802.3 document, the frame 634 counters and octet counters are always incremented together. 635 aOctetsTransmittedOK counts the number of octets in frames that were 636 counted by aFramesTransmittedOK. aOctetsReceivedOK counts the number 637 of octets in frames that were counted by aFramesReceivedOK. This is 638 not the case with the IF-MIB counters. The IF-MIB octet counters 639 count the number of octets sent to or received from the layer below 640 this interface, whereas the packet counters count the number of 641 packets sent to or received from the layer above. Therefore, 642 received MAC Control frames, ifInDiscards, and ifInUnknownProtos are 643 counted by ifInOctets, but not ifIn*castPkts. Transmitted MAC 644 Control frames are counted by ifOutOctets, but not ifOut*castPkts. 645 ifOutDiscards and ifOutErrors are counted by ifOut*castPkts, but not 646 ifOutOctets. 648 The following IEEE 802.3 managed objects have been removed from this 649 MIB module as a result of implementation feedback: 651 oMacEntity 652 .aFramesWithExcessiveDeferral 653 .aInRangeLengthErrors 654 .aOutOfRangeLengthField 655 .aMACEnableStatus 656 .aTransmitEnableStatus 657 .aMulticastReceiveStatus 658 .acInitializeMAC 660 Please see [19] for the detailed reasoning on why these objects were 661 removed. 663 In addition, the following IEEE 802.3 managed objects have not been 664 included in this MIB for the following reasons. 666 IEEE 802.3 Managed Object Disposition 668 oMACEntity 669 .aMACCapabilities Can be derived from 670 MAU-MIB - ifMauTypeListBits 672 oPHYEntity 673 .aPhyType Can be derived from 674 MAU-MIB - ifMauType 676 .aPhyTypeList Can be derived from 677 MAU-MIB - ifMauTypeListBits 679 .aMIIDetect Not considered useful. 681 .aPhyAdminState Can already obtain interface 682 state from IF-MIB - ifOperStatus 683 and MAU state from MAU-MIB - 684 ifMauStatus. Providing an 685 additional state for the PHY 686 was not considered useful. 688 .acPhyAdminControl Can already control interface 689 state from IF-MIB - ifAdminStatus 690 and MAU state from MAU-MIB - 691 ifMauStatus. Providing separate 692 admin control of the PHY was not 693 considered useful. 695 oMACControlEntity 696 .aMACControlFramesTransmitted Can be determined by summing the 697 OutFrames counters for the 698 individual control functions 700 .aMACControlFramesReceived Can be determined by summing the 701 InFrames counters for the 702 individual control functions 704 oPAUSEEntity 705 .aPAUSELinkDelayAllowance Not considered useful. 707 4. Definitions 709 EtherLike-MIB DEFINITIONS ::= BEGIN 711 IMPORTS 712 MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, 713 Counter32, mib-2, transmission 714 FROM SNMPv2-SMI 715 MODULE-COMPLIANCE, OBJECT-GROUP 716 FROM SNMPv2-CONF 717 ifIndex, InterfaceIndex 718 FROM IF-MIB; 720 etherMIB MODULE-IDENTITY 721 LAST-UPDATED "9905112310Z" -- May 11, 1999 722 ORGANIZATION "IETF Ethernet Interfaces and Hub MIB 723 Working Group" 724 CONTACT-INFO 725 "WG E-mail: hubmib@hprnd.rose.hp.com 726 To subscribe: hubmib-request@hprnd.rose.hp.com 728 Chair: Dan Romascanu 729 Postal: Lucent Technologies 730 Atidum Technology Park, Bldg. 3 731 Tel Aviv 61131 732 Israel 733 Tel: +972 3 645 8414 734 E-mail: dromasca@lucent.com 736 Editor: John Flick 737 Postal: Hewlett-Packard Company 738 8000 Foothills Blvd. M/S 5557 739 Roseville, CA 95747-5557 740 USA 741 Tel: +1 916 785 4018 742 Fax: +1 916 785 1199 743 E-mail: johnf@rose.hp.com 745 Editor: Jeffrey Johnson 746 Postal: RedBack Networks 747 2570 North First Street, Suite 410 748 San Jose, CA, 95131 749 USA 750 Tel: +1 408 571 2699 751 Fax: +1 408 571 2698 752 E-Mail: jeff@redbacknetworks.com" 754 DESCRIPTION "The MIB module to describe generic objects for 755 Ethernet-like network interfaces. 757 The following reference is used throughout this 758 MIB module: 760 [IEEE 802.3 Std] refers to: 761 IEEE Std 802.3, 1998 Edition: 'Information 762 technology - Telecommunications and 763 information exchange between systems - 764 Local and metropolitan area networks - 765 Specific requirements - Part 3: Carrier 766 sense multiple access with collision 767 detection (CSMA/CD) access method and 768 physical layer specifications', 769 September 1998. 771 Of particular interest is Clause 30, '10Mb/s, 772 100Mb/s and 1000Mb/s Management'." 774 REVISION "9905112310Z" -- May 11, 1999 775 DESCRIPTION "Updated to include support for 1000 Mb/sec 776 interfaces and full-duplex interfaces." 778 REVISION "9806032150Z" -- June 3, 1998 779 DESCRIPTION "Updated to include support for 100 Mb/sec 780 interfaces. Published as RFC 2358." 782 REVISION "9402030400Z" -- February 3, 1994 783 DESCRIPTION "Version published as RFC 1650." 784 ::= { mib-2 35 } 786 etherMIBObjects OBJECT IDENTIFIER ::= { etherMIB 1 } 788 dot3 OBJECT IDENTIFIER ::= { transmission 7 } 790 -- the Ethernet-like Statistics group 792 dot3StatsTable OBJECT-TYPE 793 SYNTAX SEQUENCE OF Dot3StatsEntry 794 MAX-ACCESS not-accessible 795 STATUS current 796 DESCRIPTION "Statistics for a collection of ethernet-like 797 interfaces attached to a particular system. 798 There will be one row in this table for each 799 ethernet-like interface in the system." 800 ::= { dot3 2 } 802 dot3StatsEntry OBJECT-TYPE 803 SYNTAX Dot3StatsEntry 804 MAX-ACCESS not-accessible 805 STATUS current 806 DESCRIPTION "Statistics for a particular interface to an 807 ethernet-like medium." 808 INDEX { dot3StatsIndex } 809 ::= { dot3StatsTable 1 } 811 Dot3StatsEntry ::= 812 SEQUENCE { 813 dot3StatsIndex InterfaceIndex, 814 dot3StatsAlignmentErrors Counter32, 815 dot3StatsFCSErrors Counter32, 816 dot3StatsSingleCollisionFrames Counter32, 817 dot3StatsMultipleCollisionFrames Counter32, 818 dot3StatsSQETestErrors Counter32, 819 dot3StatsDeferredTransmissions Counter32, 820 dot3StatsLateCollisions Counter32, 821 dot3StatsExcessiveCollisions Counter32, 822 dot3StatsInternalMacTransmitErrors Counter32, 823 dot3StatsCarrierSenseErrors Counter32, 824 dot3StatsFrameTooLongs Counter32, 825 dot3StatsInternalMacReceiveErrors Counter32, 826 dot3StatsEtherChipSet OBJECT IDENTIFIER, 827 dot3StatsSymbolErrors Counter32, 828 dot3StatsDuplexStatus INTEGER 829 } 831 dot3StatsIndex OBJECT-TYPE 832 SYNTAX InterfaceIndex 833 MAX-ACCESS read-only 834 STATUS current 835 DESCRIPTION "An index value that uniquely identifies an 836 interface to an ethernet-like medium. The 837 interface identified by a particular value of 838 this index is the same interface as identified 839 by the same value of ifIndex." 840 REFERENCE "RFC 2233, ifIndex" 841 ::= { dot3StatsEntry 1 } 843 dot3StatsAlignmentErrors OBJECT-TYPE 844 SYNTAX Counter32 845 MAX-ACCESS read-only 846 STATUS current 847 DESCRIPTION "A count of frames received on a particular 848 interface that are not an integral number of 849 octets in length and do not pass the FCS check. 851 The count represented by an instance of this 852 object is incremented when the alignmentError 853 status is returned by the MAC service to the 854 LLC (or other MAC user). Received frames for 855 which multiple error conditions obtain are, 856 according to the conventions of IEEE 802.3 857 Layer Management, counted exclusively according 858 to the error status presented to the LLC. 860 This counter does not increment for 8-bit wide 861 group encoding schemes. 863 Discontinuities in the value of this counter can 864 occur at re-initialization of the management 865 system, and at other times as indicated by the 866 value of ifCounterDiscontinuityTime." 867 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.7, 868 aAlignmentErrors" 869 ::= { dot3StatsEntry 2 } 871 dot3StatsFCSErrors OBJECT-TYPE 872 SYNTAX Counter32 873 MAX-ACCESS read-only 874 STATUS current 875 DESCRIPTION "A count of frames received on a particular 876 interface that are an integral number of octets 877 in length but do not pass the FCS check. This 878 count does not include frames received with 879 frame-too-long or frame-too-short error. 881 The count represented by an instance of this 882 object is incremented when the frameCheckError 883 status is returned by the MAC service to the 884 LLC (or other MAC user). Received frames for 885 which multiple error conditions obtain are, 886 according to the conventions of IEEE 802.3 887 Layer Management, counted exclusively according 888 to the error status presented to the LLC. 890 Note: Coding errors detected by the physical 891 layer for speeds above 10 Mb/s will cause the 892 frame to fail the FCS check. 894 Discontinuities in the value of this counter can 895 occur at re-initialization of the management 896 system, and at other times as indicated by the 897 value of ifCounterDiscontinuityTime." 898 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.6, 899 aFrameCheckSequenceErrors." 900 ::= { dot3StatsEntry 3 } 902 dot3StatsSingleCollisionFrames OBJECT-TYPE 903 SYNTAX Counter32 904 MAX-ACCESS read-only 905 STATUS current 906 DESCRIPTION "A count of successfully transmitted frames on 907 a particular interface for which transmission 908 is inhibited by exactly one collision. 910 A frame that is counted by an instance of this 911 object is also counted by the corresponding 912 instance of either the ifOutUcastPkts, 913 ifOutMulticastPkts, or ifOutBroadcastPkts, 914 and is not counted by the corresponding 915 instance of the dot3StatsMultipleCollisionFrames 916 object. 918 This counter does not increment when the 919 interface is operating in full-duplex mode. 921 Discontinuities in the value of this counter can 922 occur at re-initialization of the management 923 system, and at other times as indicated by the 924 value of ifCounterDiscontinuityTime." 925 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.3, 926 aSingleCollisionFrames." 927 ::= { dot3StatsEntry 4 } 929 dot3StatsMultipleCollisionFrames OBJECT-TYPE 930 SYNTAX Counter32 931 MAX-ACCESS read-only 932 STATUS current 933 DESCRIPTION "A count of successfully transmitted frames on 934 a particular interface for which transmission 935 is inhibited by more than one collision. 937 A frame that is counted by an instance of this 938 object is also counted by the corresponding 939 instance of either the ifOutUcastPkts, 940 ifOutMulticastPkts, or ifOutBroadcastPkts, 941 and is not counted by the corresponding 942 instance of the dot3StatsSingleCollisionFrames 943 object. 945 This counter does not increment when the 946 interface is operating in full-duplex mode. 948 Discontinuities in the value of this counter can 949 occur at re-initialization of the management 950 system, and at other times as indicated by the 951 value of ifCounterDiscontinuityTime." 952 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.4, 953 aMultipleCollisionFrames." 954 ::= { dot3StatsEntry 5 } 956 dot3StatsSQETestErrors OBJECT-TYPE 957 SYNTAX Counter32 958 MAX-ACCESS read-only 959 STATUS current 960 DESCRIPTION "A count of times that the SQE TEST ERROR 961 message is generated by the PLS sublayer for a 962 particular interface. The SQE TEST ERROR 963 is set in accordance with the rules for 964 verification of the SQE detection mechanism in 965 the PLS Carrier Sense Function as described in 966 IEEE Std. 802.3, 1998 Edition, section 7.2.4.6. 968 This counter does not increment on interfaces 969 operating at speeds greater than 10 Mb/s, or on 970 interfaces operating in full-duplex mode. 972 Discontinuities in the value of this counter can 973 occur at re-initialization of the management 974 system, and at other times as indicated by the 975 value of ifCounterDiscontinuityTime." 976 REFERENCE "[IEEE 802.3 Std.], 7.2.4.6, also 30.3.2.1.4, 977 aSQETestErrors." 978 ::= { dot3StatsEntry 6 } 980 dot3StatsDeferredTransmissions OBJECT-TYPE 981 SYNTAX Counter32 982 MAX-ACCESS read-only 983 STATUS current 984 DESCRIPTION "A count of frames for which the first 985 transmission attempt on a particular interface 986 is delayed because the medium is busy. 988 The count represented by an instance of this 989 object does not include frames involved in 990 collisions. 992 This counter does not increment when the 993 interface is operating in full-duplex mode. 995 Discontinuities in the value of this counter can 996 occur at re-initialization of the management 997 system, and at other times as indicated by the 998 value of ifCounterDiscontinuityTime." 999 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.9, 1000 aFramesWithDeferredXmissions." 1001 ::= { dot3StatsEntry 7 } 1003 dot3StatsLateCollisions OBJECT-TYPE 1004 SYNTAX Counter32 1005 MAX-ACCESS read-only 1006 STATUS current 1007 DESCRIPTION "The number of times that a collision is 1008 detected on a particular interface later than 1009 one slotTime into the transmission of a packet. 1011 A (late) collision included in a count 1012 represented by an instance of this object is 1013 also considered as a (generic) collision for 1014 purposes of other collision-related 1015 statistics. 1017 This counter does not increment when the 1018 interface is operating in full-duplex mode. 1020 Discontinuities in the value of this counter can 1021 occur at re-initialization of the management 1022 system, and at other times as indicated by the 1023 value of ifCounterDiscontinuityTime." 1024 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.10, 1025 aLateCollisions." 1026 ::= { dot3StatsEntry 8 } 1028 dot3StatsExcessiveCollisions OBJECT-TYPE 1029 SYNTAX Counter32 1030 MAX-ACCESS read-only 1031 STATUS current 1032 DESCRIPTION "A count of frames for which transmission on a 1033 particular interface fails due to excessive 1034 collisions. 1036 This counter does not increment when the 1037 interface is operating in full-duplex mode. 1039 Discontinuities in the value of this counter can 1040 occur at re-initialization of the management 1041 system, and at other times as indicated by the 1042 value of ifCounterDiscontinuityTime." 1043 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.11, 1044 aFramesAbortedDueToXSColls." 1045 ::= { dot3StatsEntry 9 } 1047 dot3StatsInternalMacTransmitErrors OBJECT-TYPE 1048 SYNTAX Counter32 1049 MAX-ACCESS read-only 1050 STATUS current 1051 DESCRIPTION "A count of frames for which transmission on a 1052 particular interface fails due to an internal 1053 MAC sublayer transmit error. A frame is only 1054 counted by an instance of this object if it is 1055 not counted by the corresponding instance of 1056 either the dot3StatsLateCollisions object, the 1057 dot3StatsExcessiveCollisions object, or the 1058 dot3StatsCarrierSenseErrors object. 1060 The precise meaning of the count represented by 1061 an instance of this object is implementation- 1062 specific. In particular, an instance of this 1063 object may represent a count of transmission 1064 errors on a particular interface that are not 1065 otherwise counted. 1067 Discontinuities in the value of this counter can 1068 occur at re-initialization of the management 1069 system, and at other times as indicated by the 1070 value of ifCounterDiscontinuityTime." 1071 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.12, 1072 aFramesLostDueToIntMACXmitError." 1073 ::= { dot3StatsEntry 10 } 1075 dot3StatsCarrierSenseErrors OBJECT-TYPE 1076 SYNTAX Counter32 1077 MAX-ACCESS read-only 1078 STATUS current 1079 DESCRIPTION "The number of times that the carrier sense 1080 condition was lost or never asserted when 1081 attempting to transmit a frame on a particular 1082 interface. 1084 The count represented by an instance of this 1085 object is incremented at most once per 1086 transmission attempt, even if the carrier sense 1087 condition fluctuates during a transmission 1088 attempt. 1090 This counter does not increment when the 1091 interface is operating in full-duplex mode. 1093 Discontinuities in the value of this counter can 1094 occur at re-initialization of the management 1095 system, and at other times as indicated by the 1096 value of ifCounterDiscontinuityTime." 1097 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.13, 1098 aCarrierSenseErrors." 1099 ::= { dot3StatsEntry 11 } 1101 -- { dot3StatsEntry 12 } is not assigned 1103 dot3StatsFrameTooLongs OBJECT-TYPE 1104 SYNTAX Counter32 1105 MAX-ACCESS read-only 1106 STATUS current 1107 DESCRIPTION "A count of frames received on a particular 1108 interface that exceed the maximum permitted 1109 frame size. 1111 The count represented by an instance of this 1112 object is incremented when the frameTooLong 1113 status is returned by the MAC service to the 1114 LLC (or other MAC user). Received frames for 1115 which multiple error conditions obtain are, 1116 according to the conventions of IEEE 802.3 1117 Layer Management, counted exclusively according 1118 to the error status presented to the LLC. 1120 Discontinuities in the value of this counter can 1121 occur at re-initialization of the management 1122 system, and at other times as indicated by the 1123 value of ifCounterDiscontinuityTime." 1124 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.25, 1125 aFrameTooLongErrors." 1126 ::= { dot3StatsEntry 13 } 1128 -- { dot3StatsEntry 14 } is not assigned 1130 -- { dot3StatsEntry 15 } is not assigned 1131 dot3StatsInternalMacReceiveErrors OBJECT-TYPE 1132 SYNTAX Counter32 1133 MAX-ACCESS read-only 1134 STATUS current 1135 DESCRIPTION "A count of frames for which reception on a 1136 particular interface fails due to an internal 1137 MAC sublayer receive error. A frame is only 1138 counted by an instance of this object if it is 1139 not counted by the corresponding instance of 1140 either the dot3StatsFrameTooLongs object, the 1141 dot3StatsAlignmentErrors object, or the 1142 dot3StatsFCSErrors object. 1144 The precise meaning of the count represented by 1145 an instance of this object is implementation- 1146 specific. In particular, an instance of this 1147 object may represent a count of receive errors 1148 on a particular interface that are not 1149 otherwise counted. 1151 Discontinuities in the value of this counter can 1152 occur at re-initialization of the management 1153 system, and at other times as indicated by the 1154 value of ifCounterDiscontinuityTime." 1155 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.15, 1156 aFramesLostDueToIntMACRcvError." 1157 ::= { dot3StatsEntry 16 } 1159 dot3StatsEtherChipSet OBJECT-TYPE 1160 SYNTAX OBJECT IDENTIFIER 1161 MAX-ACCESS read-only 1162 STATUS deprecated 1163 DESCRIPTION "******** THIS OBJECT IS DEPRECATED ******** 1165 This object contains an OBJECT IDENTIFIER 1166 which identifies the chipset used to 1167 realize the interface. Ethernet-like 1168 interfaces are typically built out of 1169 several different chips. The MIB implementor 1170 is presented with a decision of which chip 1171 to identify via this object. The implementor 1172 should identify the chip which is usually 1173 called the Medium Access Control chip. 1174 If no such chip is easily identifiable, 1175 the implementor should identify the chip 1176 which actually gathers the transmit 1177 and receive statistics and error 1178 indications. This would allow a 1179 manager station to correlate the 1180 statistics and the chip generating 1181 them, giving it the ability to take 1182 into account any known anomalies 1183 in the chip." 1184 ::= { dot3StatsEntry 17 } 1186 dot3StatsSymbolErrors OBJECT-TYPE 1187 SYNTAX Counter32 1188 MAX-ACCESS read-only 1189 STATUS current 1190 DESCRIPTION "For an interface operating at 100 Mb/s, the 1191 number of times there was an invalid data symbol 1192 when a valid carrier was present. 1194 For an interface operating in half-duplex mode 1195 at 1000 Mb/s, the number of times the receiving 1196 media is non-idle (a carrier event) for a period 1197 of time equal to or greater than slotTime, and 1198 during which there was at least one occurrence 1199 of an event that causes the PHY to indicate 1200 'Data reception error' or 'carrier extend error' 1201 on the GMII. 1203 For an interface operating in full-duplex mode 1204 at 1000 Mb/s, the number of times the receiving 1205 media is non-idle a carrier event) for a period 1206 of time equal to or greater than minFrameSize, 1207 and during which there was at least one 1208 occurrence of an event that causes the PHY to 1209 indicate 'Data reception error' on the GMII. 1211 The count represented by an instance of this 1212 object is incremented at most once per carrier 1213 event, even if multiple symbol errors occur 1214 during the carrier event. This count does 1215 not increment if a collision is present. 1217 Discontinuities in the value of this counter can 1218 occur at re-initialization of the management 1219 system, and at other times as indicated by the 1220 value of ifCounterDiscontinuityTime." 1221 REFERENCE "[IEEE 802.3 Std.], 30.3.2.1.5, 1222 aSymbolErrorDuringCarrier." 1223 ::= { dot3StatsEntry 18 } 1225 dot3StatsDuplexStatus OBJECT-TYPE 1226 SYNTAX INTEGER { 1227 unknown(1), 1228 halfDuplex(2), 1229 fullDuplex(3) 1230 } 1231 MAX-ACCESS read-only 1232 STATUS current 1233 DESCRIPTION "The current mode of operation of the MAC 1234 entity. 'unknown' indicates that the current 1235 duplex mode could not be determined. 1237 Management control of the duplex mode is 1238 accomplished through the MAU MIB. When 1239 an interface does not support autonegotiation, 1240 or when autonegotiation is not enabled, the 1241 duplex mode is controlled using 1242 ifMauDefaultType. When autonegotiation is 1243 supported and enabled, duplex mode is controlled 1244 using ifMauAutoNegAdvertisedBits. In either 1245 case, the currently operating duplex mode is 1246 reflected both in this object and in ifMauType. 1248 Note that this object provides redundant 1249 information with ifMauType. Normally, redundant 1250 objects are discouraged. However, in this 1251 instance, it allows a management application to 1252 determine the duplex status of an interface 1253 without having to know every possible value of 1254 ifMauType. This was felt to be sufficiently 1255 valuable to justify the redundancy." 1256 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.32, 1257 aDuplexStatus." 1258 ::= { dot3StatsEntry 19 } 1260 -- the Ethernet-like Collision Statistics group 1262 -- Implementation of this group is optional; it is appropriate 1263 -- for all systems which have the necessary metering 1265 dot3CollTable OBJECT-TYPE 1266 SYNTAX SEQUENCE OF Dot3CollEntry 1267 MAX-ACCESS not-accessible 1268 STATUS current 1269 DESCRIPTION "A collection of collision histograms for a 1270 particular set of interfaces." 1271 REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.30, 1272 aCollisionFrames." 1273 ::= { dot3 5 } 1275 dot3CollEntry OBJECT-TYPE 1276 SYNTAX Dot3CollEntry 1277 MAX-ACCESS not-accessible 1278 STATUS current 1279 DESCRIPTION "A cell in the histogram of per-frame 1280 collisions for a particular interface. An 1281 instance of this object represents the 1282 frequency of individual MAC frames for which 1283 the transmission (successful or otherwise) on a 1284 particular interface is accompanied by a 1285 particular number of media collisions." 1286 INDEX { ifIndex, dot3CollCount } 1287 ::= { dot3CollTable 1 } 1289 Dot3CollEntry ::= 1290 SEQUENCE { 1291 dot3CollCount INTEGER, 1292 dot3CollFrequencies Counter32 1293 } 1295 -- { dot3CollEntry 1 } is no longer in use 1297 dot3CollCount OBJECT-TYPE 1298 SYNTAX INTEGER (1..16) 1299 MAX-ACCESS not-accessible 1300 STATUS current 1301 DESCRIPTION "The number of per-frame media collisions for 1302 which a particular collision histogram cell 1303 represents the frequency on a particular 1304 interface." 1305 ::= { dot3CollEntry 2 } 1307 dot3CollFrequencies OBJECT-TYPE 1308 SYNTAX Counter32 1309 MAX-ACCESS read-only 1310 STATUS current 1311 DESCRIPTION "A count of individual MAC frames for which the 1312 transmission (successful or otherwise) on a 1313 particular interface occurs after the 1314 frame has experienced exactly the number 1315 of collisions in the associated 1316 dot3CollCount object. 1318 For example, a frame which is transmitted 1319 on interface 77 after experiencing 1320 exactly 4 collisions would be indicated 1321 by incrementing only dot3CollFrequencies.77.4. 1323 No other instance of dot3CollFrequencies would 1324 be incremented in this example. 1326 This counter does not increment when the 1327 interface is operating in full-duplex mode. 1329 Discontinuities in the value of this counter can 1330 occur at re-initialization of the management 1331 system, and at other times as indicated by the 1332 value of ifCounterDiscontinuityTime." 1333 ::= { dot3CollEntry 3 } 1335 dot3ControlTable OBJECT-TYPE 1336 SYNTAX SEQUENCE OF Dot3ControlEntry 1337 MAX-ACCESS not-accessible 1338 STATUS current 1339 DESCRIPTION "A table of descriptive and status information 1340 about the MAC Control sublayer on the 1341 ethernet-like interfaces attached to a 1342 particular system. There will be one row in 1343 this table for each ethernet-like interface in 1344 the system which implements the MAC Control 1345 sublayer. If some, but not all, of the 1346 ethernet-like interfaces in the system implement 1347 the MAC Control sublayer, there will be fewer 1348 rows in this table than in the dot3StatsTable." 1349 ::= { dot3 9 } 1351 dot3ControlEntry OBJECT-TYPE 1352 SYNTAX Dot3ControlEntry 1353 MAX-ACCESS not-accessible 1354 STATUS current 1355 DESCRIPTION "An entry in the table, containing information 1356 about the MAC Control sublayer on a single 1357 ethernet-like interface." 1358 INDEX { dot3StatsIndex } 1359 ::= { dot3ControlTable 1 } 1361 Dot3ControlEntry ::= 1362 SEQUENCE { 1363 dot3ControlFunctionsSupported BITS, 1364 dot3ControlInUnknownOpcodes Counter32 1365 } 1367 dot3ControlFunctionsSupported OBJECT-TYPE 1368 SYNTAX BITS { 1369 pause(0) -- 802.3x flow control 1371 } 1372 MAX-ACCESS read-only 1373 STATUS current 1374 DESCRIPTION "A list of the possible MAC Control functions 1375 implemented for this interface." 1376 REFERENCE "[IEEE 802.3 Std.], 30.3.3.2, 1377 aMACControlFunctionsSupported." 1378 ::= { dot3ControlEntry 1 } 1380 dot3ControlInUnknownOpcodes OBJECT-TYPE 1381 SYNTAX Counter32 1382 MAX-ACCESS read-only 1383 STATUS current 1384 DESCRIPTION "A count of MAC Control frames received on this 1385 interface that contain an opcode that is not 1386 supported by this device. 1388 Discontinuities in the value of this counter can 1389 occur at re-initialization of the management 1390 system, and at other times as indicated by the 1391 value of ifCounterDiscontinuityTime." 1392 REFERENCE "[IEEE 802.3 Std.], 30.3.3.5, 1393 aUnsupportedOpcodesReceived" 1394 ::= { dot3ControlEntry 2 } 1396 dot3PauseTable OBJECT-TYPE 1397 SYNTAX SEQUENCE OF Dot3PauseEntry 1398 MAX-ACCESS not-accessible 1399 STATUS current 1400 DESCRIPTION "A table of descriptive and status information 1401 about the MAC Control PAUSE function on the 1402 ethernet-like interfaces attached to a 1403 particular system. There will be one row in 1404 this table for each ethernet-like interface in 1405 the system which supports the MAC Control PAUSE 1406 function (i.e., the 'pause' bit in the 1407 corresponding instance of 1408 dot3ControlFunctionsSupported is set). If some, 1409 but not all, of the ethernet-like interfaces in 1410 the system implement the MAC Control PAUSE 1411 function (for example, if some interfaces only 1412 support half-duplex), there will be fewer rows 1413 in this table than in the dot3StatsTable." 1414 ::= { dot3 10 } 1416 dot3PauseEntry OBJECT-TYPE 1417 SYNTAX Dot3PauseEntry 1418 MAX-ACCESS not-accessible 1419 STATUS current 1420 DESCRIPTION "An entry in the table, containing information 1421 about the MAC Control PAUSE function on a single 1422 ethernet-like interface." 1423 INDEX { dot3StatsIndex } 1424 ::= { dot3PauseTable 1 } 1426 Dot3PauseEntry ::= 1427 SEQUENCE { 1428 dot3PauseAdminMode INTEGER, 1429 dot3PauseOperMode INTEGER, 1430 dot3InPauseFrames Counter32, 1431 dot3OutPauseFrames Counter32 1432 } 1434 dot3PauseAdminMode OBJECT-TYPE 1435 SYNTAX INTEGER { 1436 disabled(1), 1437 enabledXmit(2), 1438 enabledRcv(3), 1439 enabledXmitAndRcv(4) 1440 } 1441 MAX-ACCESS read-write 1442 STATUS current 1443 DESCRIPTION "This object is used to configure the default 1444 administrative PAUSE mode for this interface. 1446 This object represents the 1447 administratively-configured PAUSE mode for this 1448 interface. If auto-negotiation is not enabled 1449 or is not implemented for the active MAU 1450 attached to this interface, the value of this 1451 object determines the operational PAUSE mode 1452 of the interface whenever it is operating in 1453 full-duplex mode. In this case, a set to this 1454 object will force the interface into the 1455 specified mode. 1457 If auto-negotiation is implemented and enabled 1458 for the MAU attached to this interface, the 1459 PAUSE mode for this interface is determined by 1460 auto-negotiation, and the value of this object 1461 denotes the mode to which the interface will 1462 automatically revert if/when auto-negotiation is 1463 later disabled. Note that when auto-negotiation 1464 is running, administrative control of the PAUSE 1465 mode may be accomplished using the 1466 ifMauAutoNegCapAdvertisedBits object in the 1467 MAU-MIB. 1469 Note that the value of this object is ignored 1470 when the interface is not operating in 1471 full-duplex mode. 1473 An attempt to set this object to 1474 'enabledXmit(2)' or 'enabledRcv(3)' will fail 1475 on interfaces that do not support operation 1476 at greater than 100 Mb/s." 1477 ::= { dot3PauseEntry 1 } 1479 dot3PauseOperMode OBJECT-TYPE 1480 SYNTAX INTEGER { 1481 disabled(1), 1482 enabledXmit(2), 1483 enabledRcv(3), 1484 enabledXmitAndRcv(4) 1485 } 1486 MAX-ACCESS read-only 1487 STATUS current 1488 DESCRIPTION "This object reflects the PAUSE mode currently 1489 in use on this interface, as determined by 1490 either (1) the result of the auto-negotiation 1491 function or (2) if auto-negotiation is not 1492 enabled or is not implemented for the active MAU 1493 attached to this interface, by the value of 1494 dot3PauseAdminMode. Interfaces operating at 1495 100 Mb/s or less will never return 1496 'enabledXmit(2)' or 'enabledRcv(3)'. Interfaces 1497 operating in half-duplex mode will always return 1498 'disabled(1)'. Interfaces on which 1499 auto-negotiation is enabled but not yet 1500 completed should return the value 1501 'disabled(1)'." 1502 ::= { dot3PauseEntry 2 } 1504 dot3InPauseFrames OBJECT-TYPE 1505 SYNTAX Counter32 1506 MAX-ACCESS read-only 1507 STATUS current 1508 DESCRIPTION "A count of MAC Control frames received on this 1509 interface with an opcode indicating the PAUSE 1510 operation. 1512 This counter does not increment when the 1513 interface is operating in half-duplex mode. 1515 Discontinuities in the value of this counter can 1516 occur at re-initialization of the management 1517 system, and at other times as indicated by the 1518 value of ifCounterDiscontinuityTime." 1519 REFERENCE "[IEEE 802.3 Std.], 30.3.4.3, 1520 aPAUSEMACCtrlFramesReceived." 1521 ::= { dot3PauseEntry 3 } 1523 dot3OutPauseFrames OBJECT-TYPE 1524 SYNTAX Counter32 1525 MAX-ACCESS read-only 1526 STATUS current 1527 DESCRIPTION "A count of MAC Control frames transmitted on 1528 this interface with an opcode indicating the 1529 PAUSE operation. 1531 This counter does not increment when the 1532 interface is operating in half-duplex mode. 1534 Discontinuities in the value of this counter can 1535 occur at re-initialization of the management 1536 system, and at other times as indicated by the 1537 value of ifCounterDiscontinuityTime." 1538 REFERENCE "[IEEE 802.3 Std.], 30.3.4.2, 1539 aPAUSEMACCtrlFramesTransmitted." 1540 ::= { dot3PauseEntry 4 } 1542 -- 802.3 Tests 1544 dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } 1546 dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } 1548 -- TDR Test 1550 dot3TestTdr OBJECT-IDENTITY 1551 STATUS current 1552 DESCRIPTION "The Time-Domain Reflectometry (TDR) test is 1553 specific to ethernet-like interfaces of type 1554 10Base5 and 10Base2. The TDR value may be 1555 useful in determining the approximate distance 1556 to a cable fault. It is advisable to repeat 1557 this test to check for a consistent resulting 1558 TDR value, to verify that there is a fault. 1560 A TDR test returns as its result the time 1561 interval, measured in 10 MHz ticks or 100 nsec 1562 units, between the start of TDR test 1563 transmission and the subsequent detection of a 1564 collision or deassertion of carrier. On 1565 successful completion of a TDR test, the result 1566 is stored as the value of an appropriate 1567 instance of an appropriate vendor specific MIB 1568 object, and the OBJECT IDENTIFIER of that 1569 instance is stored in the appropriate instance 1570 of the appropriate test result code object 1571 (thereby indicating where the result has been 1572 stored)." 1573 ::= { dot3Tests 1 } 1575 -- Loopback Test 1577 dot3TestLoopBack OBJECT-IDENTITY 1578 STATUS current 1579 DESCRIPTION "This test configures the MAC chip and executes 1580 an internal loopback test of memory, data paths, 1581 and the MAC chip logic. This loopback test can 1582 only be executed if the interface is offline. 1583 Once the test has completed, the MAC chip should 1584 be reinitialized for network operation, but it 1585 should remain offline. 1587 If an error occurs during a test, the 1588 appropriate test result object will be set 1589 to indicate a failure. The two OBJECT 1590 IDENTIFIER values dot3ErrorInitError and 1591 dot3ErrorLoopbackError may be used to provided 1592 more information as values for an appropriate 1593 test result code object." 1594 ::= { dot3Tests 2 } 1596 dot3ErrorInitError OBJECT-IDENTITY 1597 STATUS current 1598 DESCRIPTION "Couldn't initialize MAC chip for test." 1599 ::= { dot3Errors 1 } 1601 dot3ErrorLoopbackError OBJECT-IDENTITY 1602 STATUS current 1603 DESCRIPTION "Expected data not received (or not received 1604 correctly) in loopback test." 1605 ::= { dot3Errors 2 } 1607 -- { dot3 8 }, the dot3ChipSets tree, is defined in [28] 1608 -- conformance information 1610 etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 } 1612 etherGroups OBJECT IDENTIFIER ::= { etherConformance 1 } 1613 etherCompliances OBJECT IDENTIFIER ::= { etherConformance 2 } 1615 -- compliance statements 1617 etherCompliance MODULE-COMPLIANCE 1618 STATUS deprecated 1619 DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ******** 1621 The compliance statement for managed network 1622 entities which have ethernet-like network 1623 interfaces. 1625 This compliance is deprecated and replaced by 1626 dot3Compliance." 1628 MODULE -- this module 1629 MANDATORY-GROUPS { etherStatsGroup } 1631 GROUP etherCollisionTableGroup 1632 DESCRIPTION "This group is optional. It is appropriate 1633 for all systems which have the necessary 1634 metering. Implementation in such systems is 1635 highly recommended." 1636 ::= { etherCompliances 1 } 1638 ether100MbsCompliance MODULE-COMPLIANCE 1639 STATUS deprecated 1640 DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ******** 1642 The compliance statement for managed network 1643 entities which have 100 Mb/sec ethernet-like 1644 network interfaces. 1646 This compliance is deprecated and replaced by 1647 dot3Compliance." 1649 MODULE -- this module 1650 MANDATORY-GROUPS { etherStats100MbsGroup } 1652 GROUP etherCollisionTableGroup 1653 DESCRIPTION "This group is optional. It is appropriate 1654 for all systems which have the necessary 1655 metering. Implementation in such systems is 1656 highly recommended." 1657 ::= { etherCompliances 2 } 1659 dot3Compliance MODULE-COMPLIANCE 1660 STATUS current 1661 DESCRIPTION "The compliance statement for managed network 1662 entities which have ethernet-like network 1663 interfaces." 1665 MODULE -- this module 1666 MANDATORY-GROUPS { etherStatsBaseGroup } 1668 GROUP etherDuplexGroup 1669 DESCRIPTION "This group is mandatory for all 1670 ethernet-like network interfaces which are 1671 capable of operating in full-duplex mode. 1672 It is highly recommended for all 1673 ethernet-like network interfaces." 1675 GROUP etherStatsLowSpeedGroup 1676 DESCRIPTION "This group is mandatory for all 1677 ethernet-like network interfaces which are 1678 capable of operating at 10 Mb/s or slower in 1679 half-duplex mode." 1681 GROUP etherStatsHighSpeedGroup 1682 DESCRIPTION "This group is mandatory for all 1683 ethernet-like network interfaces which are 1684 capable of operating at 100 Mb/s or faster." 1686 GROUP etherControlGroup 1687 DESCRIPTION "This group is mandatory for all 1688 ethernet-like network interfaces that 1689 support the MAC Control sublayer." 1691 GROUP etherControlPauseGroup 1692 DESCRIPTION "This group is mandatory for all 1693 ethernet-like network interfaces that 1694 support the MAC Control PAUSE function." 1696 GROUP etherCollisionTableGroup 1697 DESCRIPTION "This group is optional. It is appropriate 1698 for all ethernet-like network interfaces 1699 which are capable of operating in 1700 half-duplex mode and have the necessary 1701 metering. Implementation in systems with 1702 such interfaces is highly recommended." 1704 ::= { etherCompliances 3 } 1706 -- units of conformance 1708 etherStatsGroup OBJECT-GROUP 1709 OBJECTS { dot3StatsIndex, 1710 dot3StatsAlignmentErrors, 1711 dot3StatsFCSErrors, 1712 dot3StatsSingleCollisionFrames, 1713 dot3StatsMultipleCollisionFrames, 1714 dot3StatsSQETestErrors, 1715 dot3StatsDeferredTransmissions, 1716 dot3StatsLateCollisions, 1717 dot3StatsExcessiveCollisions, 1718 dot3StatsInternalMacTransmitErrors, 1719 dot3StatsCarrierSenseErrors, 1720 dot3StatsFrameTooLongs, 1721 dot3StatsInternalMacReceiveErrors, 1722 dot3StatsEtherChipSet 1723 } 1724 STATUS deprecated 1725 DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** 1727 A collection of objects providing information 1728 applicable to all ethernet-like network 1729 interfaces. 1731 This object group has been deprecated and 1732 replaced by etherStatsBaseGroup and 1733 etherStatsLowSpeedGroup." 1734 ::= { etherGroups 1 } 1736 etherCollisionTableGroup OBJECT-GROUP 1737 OBJECTS { dot3CollFrequencies 1738 } 1739 STATUS current 1740 DESCRIPTION "A collection of objects providing a histogram 1741 of packets successfully transmitted after 1742 experiencing exactly N collisions." 1743 ::= { etherGroups 2 } 1745 etherStats100MbsGroup OBJECT-GROUP 1746 OBJECTS { dot3StatsIndex, 1747 dot3StatsAlignmentErrors, 1748 dot3StatsFCSErrors, 1749 dot3StatsSingleCollisionFrames, 1750 dot3StatsMultipleCollisionFrames, 1751 dot3StatsDeferredTransmissions, 1752 dot3StatsLateCollisions, 1753 dot3StatsExcessiveCollisions, 1754 dot3StatsInternalMacTransmitErrors, 1755 dot3StatsCarrierSenseErrors, 1756 dot3StatsFrameTooLongs, 1757 dot3StatsInternalMacReceiveErrors, 1758 dot3StatsEtherChipSet, 1759 dot3StatsSymbolErrors 1760 } 1761 STATUS deprecated 1762 DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** 1764 A collection of objects providing information 1765 applicable to 100 Mb/sec ethernet-like network 1766 interfaces. 1768 This object group has been deprecated and 1769 replaced by etherStatsBaseGroup and 1770 etherStatsHighSpeedGroup." 1771 ::= { etherGroups 3 } 1773 etherStatsBaseGroup OBJECT-GROUP 1774 OBJECTS { dot3StatsIndex, 1775 dot3StatsAlignmentErrors, 1776 dot3StatsFCSErrors, 1777 dot3StatsSingleCollisionFrames, 1778 dot3StatsMultipleCollisionFrames, 1779 dot3StatsDeferredTransmissions, 1780 dot3StatsLateCollisions, 1781 dot3StatsExcessiveCollisions, 1782 dot3StatsInternalMacTransmitErrors, 1783 dot3StatsCarrierSenseErrors, 1784 dot3StatsFrameTooLongs, 1785 dot3StatsInternalMacReceiveErrors 1786 } 1787 STATUS current 1788 DESCRIPTION "A collection of objects providing information 1789 applicable to all ethernet-like network 1790 interfaces." 1791 ::= { etherGroups 4 } 1793 etherStatsLowSpeedGroup OBJECT-GROUP 1794 OBJECTS { dot3StatsSQETestErrors } 1795 STATUS current 1796 DESCRIPTION "A collection of objects providing information 1797 applicable to ethernet-like network interfaces 1798 capable of operating at 10 Mb/s or slower in 1799 half-duplex mode." 1801 ::= { etherGroups 5 } 1803 etherStatsHighSpeedGroup OBJECT-GROUP 1804 OBJECTS { dot3StatsSymbolErrors } 1805 STATUS current 1806 DESCRIPTION "A collection of objects providing information 1807 applicable to ethernet-like network interfaces 1808 capable of operating at 100 Mb/s or faster." 1809 ::= { etherGroups 6 } 1811 etherDuplexGroup OBJECT-GROUP 1812 OBJECTS { dot3StatsDuplexStatus } 1813 STATUS current 1814 DESCRIPTION "A collection of objects providing information 1815 about the duplex mode of an ethernet-like 1816 network interface." 1817 ::= { etherGroups 7 } 1819 etherControlGroup OBJECT-GROUP 1820 OBJECTS { dot3ControlFunctionsSupported, 1821 dot3ControlInUnknownOpcodes 1822 } 1823 STATUS current 1824 DESCRIPTION "A collection of objects providing information 1825 about the MAC Control sublayer on ethernet-like 1826 network interfaces." 1827 ::= { etherGroups 8 } 1829 etherControlPauseGroup OBJECT-GROUP 1830 OBJECTS { dot3PauseAdminMode, 1831 dot3PauseOperMode, 1832 dot3InPauseFrames, 1833 dot3OutPauseFrames 1834 } 1835 STATUS current 1836 DESCRIPTION "A collection of objects providing information 1837 about and control of the MAC Control PAUSE 1838 function on ethernet-like network interfaces." 1839 ::= { etherGroups 9 } 1841 END 1843 5. Intellectual Property 1845 The IETF takes no position regarding the validity or scope of any 1846 intellectual property or other rights that might be claimed to 1847 pertain to the implementation or use of the technology described in 1848 this document or the extent to which any license under such rights 1849 might or might not be available; neither does it represent that it 1850 has made any effort to identify any such rights. Information on the 1851 IETF's procedures with respect to rights in standards-track and 1852 standards-related documentation can be found in BCP-11. Copies of 1853 claims of rights made available for publication and any assurances of 1854 licenses to be made available, or the result of an attempt made to 1855 obtain a general license or permission for the use of such 1856 proprietary rights by implementors or users of this specification can 1857 be obtained from the IETF Secretariat. 1859 The IETF invites any interested party to bring to its attention any 1860 copyrights, patents or patent applications, or other proprietary 1861 rights which may cover technology that may be required to practice 1862 this standard. Please address the information to the IETF Executive 1863 Director. 1865 6. Acknowledgements 1867 This document was produced by the IETF Ethernet Interfaces and Hub 1868 MIB Working Group, whose efforts were greatly advanced by the 1869 contributions of the following people: 1871 Lynn Kubinec 1872 Steve McRobert 1873 Dan Romascanu 1874 Andrew Smith 1875 Geoff Thompson 1877 This document is based on the Proposed Standard Ethernet MIB, RFC 1878 2358 [23], edited by John Flick of Hewlett-Packard and Jeffrey 1879 Johnson of RedBack Networks and produced by the 802.3 Hub MIB Working 1880 Group. It extends that document by providing support for full-duplex 1881 Ethernet interfaces and 1000 Mb/sec Ethernet interfaces as outlined 1882 in [16]. 1884 RFC 2358, in turn, is almost completely based on both the Standard 1885 Ethernet MIB, RFC 1643 [21], and the Proposed Standard Ethernet MIB 1886 using the SNMPv2 SMI, RFC 1650 [22], both of which were edited by 1887 Frank Kastenholz of FTP Software and produced by the Interfaces MIB 1888 Working Group. RFC 2358 extends those documents by providing support 1889 for 100 Mb/sec ethernet interfaces. 1891 RFC 1643 and RFC 1650, in turn, are based on the Draft Standard 1892 Ethernet MIB, RFC 1398 [20], also edited by Frank Kastenholz and 1893 produced by the Ethernet MIB Working Group. 1895 RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB, 1896 RFC 1284 [18], which was edited by John Cook of Chipcom and produced 1897 by the Transmission MIB Working Group. The Ethernet MIB Working 1898 Group gathered implementation experience of the variables specified 1899 in RFC 1284, documented that experience in RFC 1369 [19], and used 1900 that information to develop this revised MIB. 1902 RFC 1284, in turn, is based on a document written by Frank 1903 Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management 1904 Draft M compatible MIB for TCP/IP Networks [17]. This document was 1905 modestly reworked, initially by the SNMP Working Group, and then by 1906 the Transmission Working Group, to reflect the current conventions 1907 for defining objects for MIB interfaces. James Davin, of the MIT 1908 Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN 1909 Systems, contributed to later drafts of this memo. Marshall Rose of 1910 Performance Systems International, Inc. converted the document into 1911 RFC 1212 [3] concise format. Anil Rijsinghani of DEC contributed 1912 text that more adequately describes the TDR test. Thanks to Frank 1913 Kastenholz of Interlan and Louis Steinberg of IBM for their 1914 experimentation. 1916 7. References 1918 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1919 Describing SNMP Management Frameworks", RFC 2571, Cabletron 1920 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 1921 May 1999 1923 [2] Rose, M., and K. McCloghrie, "Structure and Identification of 1924 Management Information for TCP/IP-based Internets", RFC 1155, 1925 STD 16, Performance Systems International, Hughes LAN Systems, 1926 May 1990 1928 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1929 1212, STD 16, Performance Systems International, Hughes LAN 1930 Systems, March 1991 1932 [4] M. Rose, "A Convention for Defining Traps for use with the 1933 SNMP", RFC 1215, Performance Systems International, March 1991 1935 [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 1936 M., and S Waldbusser, "Structure of Management Information 1937 Version 2 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPInfo, 1938 TU Braunschweig, SNMP Research, First Virtual Holdings, 1939 International Network Services, April 1999. 1941 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 1942 M., and S Waldbusser, "Textual Conventions for SMIv2", RFC 2579, 1943 STD 58, Cisco Systems, SNMPInfo, TU Braunschweig, SNMP Research, 1944 First Virtual Holdings, International Network Services, 1945 April 1999. 1947 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 1948 M., and S Waldbusser, "Conformance Statements for SMIv2", RFC 1949 2580, STD 58, Cisco Systems, SNMPInfo, TU Braunschweig, SNMP 1950 Research, First Virtual Holdings, International Network 1951 Services, April 1999. 1953 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1954 Network Management Protocol", STD 15, RFC 1157, SNMP Research, 1955 Performance Systems International, Performance Systems 1956 International, MIT Laboratory for Computer Science, May 1990. 1958 [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1959 "Introduction to Community-based SNMPv2", RFC 1901, SNMP 1960 Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 1961 Inc., International Network Services, January 1996. 1963 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1964 "Transport Mappings for Version 2 of the Simple Network 1965 Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., 1966 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1967 Network Services, January 1996. 1969 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1970 Processing and Dispatching for the Simple Network Management 1971 Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron 1972 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 1973 May 1999. 1975 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) 1976 for version 3 of the Simple Network Management Protocol 1977 (SNMPv3)", RFC 2574, IBM T. J. Watson Research, May 1999. 1979 [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1980 Operations for Version 2 of the Simple Network Management 1981 Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco 1982 Systems, Inc., Dover Beach Consulting, Inc., International 1983 Network Services, January 1996. 1985 [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1986 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco 1987 Systems, May 1999 1989 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1990 Control Model (VACM) for the Simple Network Management Protocol 1991 (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, 1992 Inc., Cisco Systems, Inc., May 1999 1994 [16] IEEE, IEEE Std 802.3, 1998 Edition: "Information technology - 1995 Telecommunications and information exchange between systems - 1996 Local and metropolitan area networks - Specific requirements - 1997 Part 3: Carrier sense multiple access with collision detection 1998 (CSMA/CD) access method and physical layer specifications" 1999 (incorporating ANSI/IEEE Std. 802.3, 1996 Edition, IEEE Std. 2000 802.3r-1996, 802.3u-1995, 802.3x&y-1997, 802.3z-1998, and 2001 802.3aa-1998), September 1998. 2003 [17] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible 2004 MIB for TCP/IP Networks", electronic mail message to mib- 2005 wg@nnsc.nsf.net, 9 June 1989. 2007 [18] Cook, J., "Definitions of Managed Objects for Ethernet-Like 2008 Interface Types", RFC 1284, Chipcom Corporation, December 1991. 2010 [19] Kastenholz, F., "Implementation Notes and Experience for The 2011 Internet Ethernet MIB", RFC 1369, FTP Software, October 1992. 2013 [20] Kastenholz, F., "Definitions of Managed Objects for the 2014 Ethernet-like Interface Types", RFC 1398, FTP Software, Inc., 2015 January 1993. 2017 [21] Kastenholz, F., "Definitions of Managed Objects for the 2018 Ethernet-like Interface Types", STD 50, RFC 1643, FTP Software, 2019 Inc., July 1994. 2021 [22] Kastenholz, F., "Definitions of Managed Objects for the 2022 Ethernet-like Interface Types using SMIv2", RFC 1650, 2023 FTP Software, Inc., August 1994. 2025 [23] Flick, J., and J. Johnson, "Definitions of Managed Objects 2026 for the Ethernet-like Interface Types", RFC 2358, 2027 Hewlett-Packard Company, RedBack Networks, June 1998. 2029 [24] McCloghrie, K., and M. Rose, Editors, "Management Information 2030 Base for Network Management of TCP/IP-based internets: MIB-II", 2031 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 2032 International, March 1991. 2034 [25] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB 2035 using SMIv2", RFC 2233, Cisco Systems, FTP Software, 2036 November 1997. 2038 [26] Bradner, S., "Key words for use in RFCs to Indicate 2039 Requirements Levels", BCP 14, RFC 2119, March 1997. 2041 [27] Smith, A., Flick, J., deGraaf, K., Romascanu, D., McMaster, 2042 D., McCloghrie, K., and S. Roberts, "Definitions of Managed 2043 Objects for IEEE 802.3 Medium Attachment Units (MAUs) using 2044 SMIv2", work in progress, draft-ietf-hubmib-mau-mib-v2-02.txt, 2045 Extreme Networks, Inc., Hewlett-Packard Company, Argon Networks, 2046 LANNET Ltd., Cisco Systems, Inc., Cisco Systems Inc., Farallon 2047 Computing Inc., January 1999. 2049 [28] Flick, J., "Definitions of Object Identifiers for Identifying 2050 Ethernet Chip Sets", work in progress, 2051 draft-ietf-hubmib-ether-chipsets-00.txt, Hewlett-Packard 2052 Company, January 1999. 2054 8. Security Considerations 2056 There are two management objects defined in this MIB that have a 2057 MAX-ACCESS clause of read-write. Such objects may be considered 2058 sensitive or vulnerable in some network environments. The support 2059 for SET operations in a non-secure environment without proper 2060 protection can have a negative effect on network operations. 2062 There are a number of managed objects in this MIB that may be 2063 considered to contain sensitive information. In particular, the 2064 dot3StatsEtherChipSet object may be considered sensitive in many 2065 environments, since it would allow an intruder to obtain information 2066 about which vendor's equipment is in use on the network. Note that 2067 this object has been deprecated. However, some implementors may 2068 still choose to implement it for backwards compatability. 2070 Therefore, it may be important in some environments to control read 2071 access to these objects and possibly to even encrypt the values of 2072 these objects when sending them over the network via SNMP. Not all 2073 versions of SNMP provide features for such a secure environment. 2075 SNMPv1 by itself is such an insecure environment. Even if the 2076 network itself is secure (for example by using IPSec), even then, 2077 there is no control as to who on the secure network is allowed to 2078 access and GET (read) the objects in this MIB. 2080 It is recommended that the implementors consider the security 2081 features as provided by the SNMPv3 framework. Specifically, the use 2082 of the User-based Security Model RFC 2574 [12] and the View-based 2083 Access Control Model RFC 2575 [15] is recommended. 2085 It is then a customer/user responsibility to ensure that the SNMP 2086 entity giving access to an instance of this MIB, is properly 2087 configured to give access to those objects only to those principals 2088 (users) that have legitimate rights to access them. 2090 9. Author's Addresses 2092 John Flick 2093 Hewlett-Packard Company 2094 8000 Foothills Blvd. M/S 5557 2095 Roseville, CA 95747-5557 2097 Phone: +1 916 785 4018 2098 Email: johnf@rose.hp.com 2100 Jeffrey Johnson 2101 RedBack Networks 2102 2570 North First Street, Suite 410 2103 San Jose, CA, 95131, USA 2105 Phone: +1 408 571 2699 2106 EMail: jeff@redbacknetworks.com 2108 A. Change Log 2110 A.1. Changes since RFC 2358 2112 This section enumerates changes made to RFC 2358 to produce this 2113 document. 2115 (1) Section 2 has been replaced with the current SNMP 2116 Management Framework boilerplate. 2118 (2) The ifMtu mapping has been clarified. 2120 (3) The relationship between the IEEE 802.3 octet counters 2121 and the IF-MIB octet counters has been clarified. 2123 (4) REFERENCE clauses have been updated to reflect the 2124 actual IEEE 802.3 managed object that each MIB object 2125 is based on. 2127 (5) The following object DESCRIPTION clauses have been 2128 updated to reflect that they do not increment in 2129 full-duplex mode: dot3StatsSingleCollisionFrames, 2130 dot3StatsMultipleCollisionFrames, dot3StatsSQETestErrors, 2131 dot3StatsDeferredTransmissions, dot3StatsLateCollisions, 2132 dot3StatsExcessiveCollisions, dot3StatsCarrierSenseErrors, 2133 dot3CollFrequencies. 2135 (6) The following object DESCRIPTION clauses have been 2136 updated to reflect behaviour on full-duplex and 2137 1000 Mb/s interfaces: dot3StatsAlignmentErrors, 2138 dot3StatsFCSErrors, dot3StatsSQETestErrors, 2139 dot3StatsLateCollisions, dot3StatsSymbolErrors. 2141 (7) Two new tables, dot3ControlTable and dot3PauseTable, 2142 have been added. 2144 (8) A new object, dot3StatsDuplexStatus, has been added. 2146 (9) The object groups and compliances have been restructured. 2148 (10) The dot3StatsEtherChipSet object has been deprecated. 2150 (11) The dot3ChipSets have been moved to a separate document. 2152 A.2. Changes between RFC 1650 and RFC 2358 2154 This section enumerates changes made to RFC 1650 to produce RFC 2358. 2156 (1) The MODULE-IDENTITY has been updated to reflect the changes 2157 in the MIB. 2159 (2) A new object, dot3StatsSymbolErrors, has been added. 2161 (3) The definition of the object dot3StatsIndex has been 2162 converted to use the SMIv2 OBJECT-TYPE macro. 2164 (4) A new conformance group, etherStats100MbsGroup, has been 2165 added. 2167 (5) A new compliance statement, ether100MbsCompliance, has 2168 been added. 2170 (6) The Acknowledgements were extended to provide a more 2171 complete history of the origin of this document. 2173 (7) The discussion of ifType has been expanded. 2175 (8) A section on mapping of Interfaces MIB objects has 2176 been added. 2178 (9) A section defining the relationship of this MIB to 2179 the MAU MIB has been added. 2181 (10) A section on the mapping of IEEE 802.3 managed objects 2182 to this MIB and the Interfaces MIB has been added. 2184 (11) Converted the dot3Tests, dot3Errors, and dot3ChipSets 2185 OIDs to use the OBJECT-IDENTITY macro. 2187 (12) Added to the list of registered dot3ChipSets. 2189 (13) An intellectual property notice and copyright notice 2190 were added, as required by RFC 2026. 2192 B. Full Copyright Statement 2194 This document and translations of it may be copied and furnished to 2195 others, and derivative works that comment on or otherwise explain it 2196 or assist in its implementation may be prepared, copied, published 2197 and distributed, in whole or in part, without restriction of any 2198 kind, provided that the above copyright notice and this paragraph are 2199 included on all such copies and derivative works. However, this 2200 document itself may not be modified in any way, such as by removing 2201 the copyright notice or references to the Internet Society or other 2202 Internet organizations, except as needed for the purpose of 2203 developing Internet standards in which case the procedures for 2204 copyrights defined in the Internet Standards process must be 2205 followed, or as required to translate it into languages other than 2206 English. 2208 The limited permissions granted above are perpetual and will not be 2209 revoked by the Internet Society or its successors or assigns. 2211 This document and the information contained herein is provided on an 2212 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2213 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2214 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2215 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2216 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.