idnits 2.17.1 draft-ietf-hubmib-etherif-mib-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 187: '...y needed objects MUST be provided in t...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 1996) is 10175 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1902 (ref. '2') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '3') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '4') (Obsoleted by RFC 2580) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1284 (ref. '8') (Obsoleted by RFC 1398) ** Obsolete normative reference: RFC 1398 (ref. '9') (Obsoleted by RFC 1623) ** Obsolete normative reference: RFC 1623 (ref. '10') (Obsoleted by RFC 1643) ** Obsolete normative reference: RFC 1650 (ref. '11') (Obsoleted by RFC 2358) ** Obsolete normative reference: RFC 1573 (ref. '12') (Obsoleted by RFC 2233) Summary: 18 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Hub MIB Working Group J. Johnson 3 INTERNET DRAFT cisco Systems, Inc. 4 June 1996 6 Definitions of Managed Objects for 7 the Ethernet-like Interface Types 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This memo is an extension to the SNMP MIB. It specifies an IAB 32 standards track protocol for the Internet community, and requests 33 discussion and suggestions for improvements. The origin of this memo is 34 from RFC 1650 "Definitions of Managed Objects for the Ethernet-like 35 Interface Types using SMIv2." This memo extends that specification by 36 including management information useful for the management of 100-BaseT 37 ethernet interfaces. 39 Distribution of this memo is unlimited. Please forward comments to 40 hubmib@hprnd.rose.hp.com. 42 1. Introduction 44 This memo defines a portion of the Management Information Base (MIB) for 45 use with network management protocols in the Internet community. In 46 particular, it defines objects for managing ethernet-like interfaces. 48 This memo also includes a MIB module. This MIB module extends the list 49 of managed objects specified in the earlier version of this MIB: RFC1650 50 [11]. 52 2. The SNMP Network Management Framework 54 The SNMP Network Management Framework consists of several components. 55 For the purpose of this specification, the applicable components of the 56 Framework are the SMI and related documents [2, 3, 4], which define the 57 mechanisms used for describing and naming objects for the purpose of 58 management. 60 The Framework permits new objects to be defined for the purpose of 61 experimentation and evaluation. 63 2.1. Object Definitions 65 Managed objects are accessed via a virtual information store, termed the 66 Management Information Base or MIB. Objects in the MIB are defined 67 using the subset of Abstract Syntax Notation One (ASN.1) [1] defined in 68 the SMI [2]. In particular, each object object type is named by an 69 OBJECT IDENTIFIER, an administratively assigned name. The object type 70 together with an object instance serves to uniquely identify a specific 71 instantiation of the object. For human convenience, we often use a 72 textual string, termed the descriptor, to refer to the object type. 74 3. Change Log 76 This section enumerates changes made to RFC 1650 to produce this 77 document. 79 (1) The MODULE-IDENTITY has been updated to reflect the changes 80 in the MIB. 82 (2) A new object, dot3StatsSymbolErrors, has been added. 84 (3) The description of the object dot3StatsSQETestErrors has 85 been updated to reflect the fact that this object is not 86 applicable to 100Base-T interfaces. 88 (4) The definition of the object dot3StatsIndex has been 89 converted to use the SMIv2 OBJECT-TYPE macro. 91 (5) A new conformance group, etherStats100MbsGroup, has been 92 added. 94 (6) A new compliance statement, ether100MbsCompliance, has 95 been added. 97 (7) The Acknowledgements were extended to provide a more 98 complete history of the origin of this document. 100 4. Overview 102 Instances of these object types represent attributes of an interface to 103 an ethernet-like communications medium. At present, ethernet-like media 104 are identified by the following values of the ifType object in the 105 Interfaces MIB [12]: 107 ethernet-csmacd(6) 108 iso88023-csmacd(7) 109 starLan(11) 110 fastEther(62) 111 fastEtherFX(69) 113 The definitions presented here are based on the IEEE 802.3 Layer 114 Management Specification [5], as originally interpreted by Frank 115 Kastenholz then of Interlan in [7]. Implementors of these MIB objects 116 should note that the IEEE document explicitly describes (in the form of 117 Pascal pseudocode) when, where, and how various MAC attributes are 118 measured. The IEEE document also describes the effects of MAC actions 119 that may be invoked by manipulating instances of the MIB objects defined 120 here. 122 To the extent that some of the attributes defined in [5] are represented 123 by previously defined objects in the Internet-standard MIB or in the 124 Interfaces Group Evolution MIB [12], such attributes are not redundantly 125 represented by objects defined in this memo. Among the attributes 126 represented by objects defined in other memos are the number of octets 127 transmitted or received on a particular interface, the number of frames 128 transmitted or received on a particular interface, the promiscuous 129 status of an interface, the MAC address of an interface, and multicast 130 information associated with an interface. 132 4.1. Relation to RFC 1213 133 This section applies only when this MIB is used in conjunction with the 134 "old" (i.e., pre-RFC 1573) interface group. 136 The relationship between an ethernet-like interface and an interface in 137 the context of the Internet-standard MIB is one-to-one. As such, the 138 value of an ifIndex object instance can be directly used to identify 139 corresponding instances of the objects defined herein. 141 For agents which implement the (now deprecated) ifSpecific object, an 142 instance of that object that is associated with an ethernet-like 143 interface has the OBJECT IDENTIFIER value: 145 dot3 OBJECT IDENTIFER ::= { transmission 7 } 147 4.2. Relation to RFC 1573 149 RFC 1573, the Interface MIB Evolution, requires that any MIB which is an 150 adjunct of the Interface MIB, clarify specific areas within the 151 Interface MIB. These areas were intentionally left vague in RFC 1573 to 152 avoid over constraining the MIB, thereby precluding management of 153 certain media-types. 155 Section 3.3 of RFC 1573 enumerates several areas which a media- specific 156 MIB must clarify. Each of these areas is addressed in a following 157 subsection. The implementor is referred to RFC 1573 in order to 158 understand the general intent of these areas. 160 4.2.1. Layering Model 162 This MIB does not provide for layering. There are no sublayers. 164 EDITOR'S NOTE: 166 One could forsee the development of an 802.2 and enet-transceiver MIB. 167 They could be higher and lower sublayers, respectively. All that THIS 168 document should do is allude to the possibilities and urge the 169 implementor to be aware of the possibility and that they may have 170 requirements which supersede the requirements in this document. 172 4.2.2. Virtual Circuits 174 This medium does not support virtual circuits and this area is not 175 applicable to this MIB. 177 4.2.3. ifTestTable 179 This MIB defines two tests for media which are instumented with this 180 MIB; TDR and Loopback. Implementation of these tests is not required. 181 Many common interface chips do not support one or both of these tests. 183 These two tests are provided as a convenience, allowing a common method 184 to invoke the test. 186 Standard MIBs do not include objects in which to return the results of 187 the TDR test. Any needed objects MUST be provided in the vendor 188 specific MIB. 190 4.2.4. ifRcvAddressTable 192 This table contains all IEEE 802.3 addresses, unicast, multicast, and 193 broadcast, for which this interface will receive packets and forward 194 them up to a higher layer entity for local consumption. The format of 195 the address, contained in ifRcvAddressAddress, is the same as for 196 ifPhysAddress. 198 In the event that the interface is part of a MAC bridge, this table does 199 not include unicast addresses which are accepted for possible forwarding 200 out some other port. This table is explicitly not intended to provide a 201 bridge address filtering mechanism. 203 4.2.5. ifPhysAddress 205 This object contains the IEEE 802.3 address which is placed in the 206 source-address field of any Ethernet, Starlan, or IEEE 802.3 frames that 207 originate at this interface. Usually this will be kept in ROM on the 208 interface hardware. Some systems may set this address via software. 210 In a system where there are several such addresses the designer has a 211 tougher choice. The address chosen should be the one most likely to be 212 of use to network management (e.g. the address placed in ARP responses 213 for systems which are primarily IP systems). 215 If the designer truly can not chose, use of the factory- provided ROM 216 address is suggested. 218 If the address can not be determined, an octet string of zero length 219 should be returned. 221 The address is stored in binary in this object. The address is stored 222 in "canonical" bit order, that is, the Group Bit is positioned as the 223 low-order bit of the first octet. Thus, the first byte of a multicast 224 address would have the bit 0x01 set. 226 4.2.6. ifType 228 This MIB applies to interfaces which have any of the following ifType 229 values: 231 ethernet-csmacd(6) 232 iso88023-csmacd(7) 233 starLan(11) 234 fastEther(62) 235 fastEtherFX(69) 237 Interfaces with any of the first three ifType values map to the 238 EtherLike-MIB in the same manner. The EtherLike-MIB etherCompliance 239 compliance statement applies equally to all three types; there are no 240 implementation differences. Similiarly, interfaces with either of the 241 last two ifType values map to the EtherLike-MIB in the same manner. The 242 EtherLike-MIB ether100MbsCompliance compliance statement applies equally 243 to both types; there are no implementation differences. 245 5. Definitions 247 EtherLike-MIB DEFINITIONS ::= BEGIN 249 IMPORTS 250 MODULE-IDENTITY, OBJECT-TYPE, Counter32, mib-2 FROM SNMPv2-SMI 251 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 252 ifIndex, InterfaceIndex FROM IF-MIB; 254 etherMIB MODULE-IDENTITY 255 LAST-UPDATED "9606052300Z" 256 ORGANIZATION "IETF 802.3 Hub MIB Working Group" 257 CONTACT-INFO 258 "WG E-mail: hubmib@hprnd.rose.hp.com 260 Editor: Jeffrey Johnson 261 Postal: cisco Systems, Inc. 262 170 W.Tasman Drive 263 San Jose, CA, 94015 264 USA 265 Tel: +1 408 526 7789 266 E-Mail: jjohnson@cisco.com" 267 DESCRIPTION 268 "The MIB module to describe generic objects for 269 Ethernet-like network interfaces. This MIB is an 270 updated version of the Ethernet-like MIB in RFC 271 1650." 272 REVISION "9606052300Z" 273 DESCRIPTION 274 "Updated to include support for 100 Mb/sec interfaces." 275 ::= { mib-2 35 } 277 etherMIBObjects OBJECT IDENTIFIER ::= { etherMIB 1 } 279 dot3 OBJECT IDENTIFIER ::= { transmission 7 } 281 -- the Ethernet-like Statistics group 283 dot3StatsTable OBJECT-TYPE 284 SYNTAX SEQUENCE OF Dot3StatsEntry 285 MAX-ACCESS not-accessible 286 STATUS current 287 DESCRIPTION 288 "Statistics for a collection of ethernet-like 289 interfaces attached to a particular system." 290 ::= { dot3 2 } 292 dot3StatsEntry OBJECT-TYPE 293 SYNTAX Dot3StatsEntry 294 MAX-ACCESS not-accessible 295 STATUS current 296 DESCRIPTION 297 "Statistics for a particular interface to an 298 ethernet-like medium." 299 INDEX { dot3StatsIndex } 300 ::= { dot3StatsTable 1 } 302 Dot3StatsEntry ::= SEQUENCE { 303 dot3StatsIndex InterfaceIndex, 304 dot3StatsAlignmentErrors Counter32, 305 dot3StatsFCSErrors Counter32, 306 dot3StatsSingleCollisionFrames Counter32, 307 dot3StatsMultipleCollisionFrames Counter32, 308 dot3StatsSQETestErrors Counter32, 309 dot3StatsDeferredTransmissions Counter32, 310 dot3StatsLateCollisions Counter32, 311 dot3StatsExcessiveCollisions Counter32, 312 dot3StatsInternalMacTransmitErrors Counter32, 313 dot3StatsCarrierSenseErrors Counter32, 314 dot3StatsFrameTooLongs Counter32, 315 dot3StatsInternalMacReceiveErrors Counter32, 316 dot3StatsEtherChipSet OBJECT IDENTIFIER, 317 dot3StatsSymbolErrors Counter32 318 } 320 dot3StatsIndex OBJECT-TYPE 321 SYNTAX InterfaceIndex 322 MAX-ACCESS read-only 323 STATUS current 324 DESCRIPTION 325 "An index value that uniquely identifies an 326 interface to an ethernet-like medium. The 327 interface identified by a particular value of 328 this index is the same interface as identified 329 by the same value of ifIndex." 330 ::= { dot3StatsEntry 1 } 332 dot3StatsAlignmentErrors OBJECT-TYPE 333 SYNTAX Counter32 334 MAX-ACCESS read-only 335 STATUS current 336 DESCRIPTION 337 "A count of frames received on a particular 338 interface that are not an integral number of 339 octets in length and do not pass the FCS check. 341 The count represented by an instance of this 342 object is incremented when the alignmentError 343 status is returned by the MAC service to the 344 LLC (or other MAC user). Received frames for 345 which multiple error conditions obtain are, 346 according to the conventions of IEEE 802.3 347 Layer Management, counted exclusively according 348 to the error status presented to the LLC." 349 REFERENCE 350 "IEEE 802.3 Layer Management" 351 ::= { dot3StatsEntry 2 } 353 dot3StatsFCSErrors OBJECT-TYPE 354 SYNTAX Counter32 355 MAX-ACCESS read-only 356 STATUS current 357 DESCRIPTION 358 "A count of frames received on a particular 359 interface that are an integral number of octets 360 in length but do not pass the FCS check. 362 The count represented by an instance of this 363 object is incremented when the frameCheckError 364 status is returned by the MAC service to the 365 LLC (or other MAC user). Received frames for 366 which multiple error conditions obtain are, 367 according to the conventions of IEEE 802.3 368 Layer Management, counted exclusively according 369 to the error status presented to the LLC." 370 REFERENCE 371 "IEEE 802.3 Layer Management" 372 ::= { dot3StatsEntry 3 } 374 dot3StatsSingleCollisionFrames OBJECT-TYPE 375 SYNTAX Counter32 376 MAX-ACCESS read-only 377 STATUS current 378 DESCRIPTION 379 "A count of successfully transmitted frames on 380 a particular interface for which transmission 381 is inhibited by exactly one collision. 383 A frame that is counted by an instance of this 384 object is also counted by the corresponding 385 instance of either the ifOutUcastPkts, 386 ifOutMulticastPkts, or ifOutBroadcastPkts, 387 and is not counted by the corresponding 388 instance of the dot3StatsMultipleCollisionFrames 389 object." 390 REFERENCE 391 "IEEE 802.3 Layer Management" 392 ::= { dot3StatsEntry 4 } 394 dot3StatsMultipleCollisionFrames OBJECT-TYPE 395 SYNTAX Counter32 396 MAX-ACCESS read-only 397 STATUS current 398 DESCRIPTION 399 "A count of successfully transmitted frames on 400 a particular interface for which transmission 401 is inhibited by more than one collision. 403 A frame that is counted by an instance of this 404 object is also counted by the corresponding 405 instance of either the ifOutUcastPkts, 406 ifOutMulticastPkts, or ifOutBroadcastPkts, 407 and is not counted by the corresponding 408 instance of the dot3StatsSingleCollisionFrames 409 object." 410 REFERENCE 411 "IEEE 802.3 Layer Management" 412 ::= { dot3StatsEntry 5 } 414 dot3StatsSQETestErrors OBJECT-TYPE 415 SYNTAX Counter32 416 MAX-ACCESS read-only 417 STATUS current 418 DESCRIPTION 419 "A count of times that the SQE TEST ERROR 420 message is generated by the PLS sublayer for a 421 particular interface. The SQE TEST ERROR 422 message is defined in section 7.2.2.2.4 of 423 ANSI/IEEE 802.3-1985 and its generation is 424 described in section 7.2.4.6 of the same 425 document. 427 The SQE test function is not a part of 100 Mb/sec 428 operation, so an instance of this object need not 429 be present for 100 Mb/sec interfaces." 430 REFERENCE 431 "ANSI/IEEE Std 802.3-1985 Carrier Sense 432 Multiple Access with Collision Detection Access 433 Method and Physical Layer Specifications" 434 ::= { dot3StatsEntry 6 } 436 dot3StatsDeferredTransmissions OBJECT-TYPE 437 SYNTAX Counter32 438 MAX-ACCESS read-only 439 STATUS current 440 DESCRIPTION 441 "A count of frames for which the first 442 transmission attempt on a particular interface 443 is delayed because the medium is busy. 445 The count represented by an instance of this 446 object does not include frames involved in 447 collisions." 448 REFERENCE 449 "IEEE 802.3 Layer Management" 450 ::= { dot3StatsEntry 7 } 452 dot3StatsLateCollisions OBJECT-TYPE 453 SYNTAX Counter32 454 MAX-ACCESS read-only 455 STATUS current 456 DESCRIPTION 457 "The number of times that a collision is 458 detected on a particular interface later than 459 512 bit-times into the transmission of a 460 packet. 462 Five hundred and twelve bit-times corresponds 463 to 51.2 microseconds on a 10 Mbit/s system. A 464 (late) collision included in a count 465 represented by an instance of this object is 466 also considered as a (generic) collision for 467 purposes of other collision-related 468 statistics." 469 REFERENCE 470 "IEEE 802.3 Layer Management" 471 ::= { dot3StatsEntry 8 } 473 dot3StatsExcessiveCollisions OBJECT-TYPE 474 SYNTAX Counter32 475 MAX-ACCESS read-only 476 STATUS current 477 DESCRIPTION 478 "A count of frames for which transmission on a 479 particular interface fails due to excessive 480 collisions." 481 REFERENCE 482 "IEEE 802.3 Layer Management" 483 ::= { dot3StatsEntry 9 } 485 dot3StatsInternalMacTransmitErrors OBJECT-TYPE 486 SYNTAX Counter32 487 MAX-ACCESS read-only 488 STATUS current 489 DESCRIPTION 490 "A count of frames for which transmission on a 491 particular interface fails due to an internal 492 MAC sublayer transmit error. A frame is only 493 counted by an instance of this object if it is 494 not counted by the corresponding instance of 495 either the dot3StatsLateCollisions object, the 496 dot3StatsExcessiveCollisions object, or the 497 dot3StatsCarrierSenseErrors object. 499 The precise meaning of the count represented by 500 an instance of this object is implementation- 501 specific. In particular, an instance of this 502 object may represent a count of transmission 503 errors on a particular interface that are not 504 otherwise counted." 505 REFERENCE 506 "IEEE 802.3 Layer Management" 507 ::= { dot3StatsEntry 10 } 509 dot3StatsCarrierSenseErrors OBJECT-TYPE 510 SYNTAX Counter32 511 MAX-ACCESS read-only 512 STATUS current 513 DESCRIPTION 514 "The number of times that the carrier sense 515 condition was lost or never asserted when 516 attempting to transmit a frame on a particular 517 interface. 519 The count represented by an instance of this 520 object is incremented at most once per 521 transmission attempt, even if the carrier sense 522 condition fluctuates during a transmission 523 attempt." 524 REFERENCE 525 "IEEE 802.3 Layer Management" 526 ::= { dot3StatsEntry 11 } 528 -- { dot3StatsEntry 12 } is not assigned 530 dot3StatsFrameTooLongs OBJECT-TYPE 531 SYNTAX Counter32 532 MAX-ACCESS read-only 533 STATUS current 534 DESCRIPTION 535 "A count of frames received on a particular 536 interface that exceed the maximum permitted 537 frame size. 539 The count represented by an instance of this 540 object is incremented when the frameTooLong 541 status is returned by the MAC service to the 542 LLC (or other MAC user). Received frames for 543 which multiple error conditions obtain are, 544 according to the conventions of IEEE 802.3 545 Layer Management, counted exclusively according 546 to the error status presented to the LLC." 547 REFERENCE 548 "IEEE 802.3 Layer Management" 549 ::= { dot3StatsEntry 13 } 551 -- { dot3StatsEntry 14 } is not assigned 553 -- { dot3StatsEntry 15 } is not assigned 555 dot3StatsInternalMacReceiveErrors OBJECT-TYPE 556 SYNTAX Counter32 557 MAX-ACCESS read-only 558 STATUS current 559 DESCRIPTION 560 "A count of frames for which reception on a 561 particular interface fails due to an internal 562 MAC sublayer receive error. A frame is only 563 counted by an instance of this object if it is 564 not counted by the corresponding instance of 565 either the dot3StatsFrameTooLongs object, the 566 dot3StatsAlignmentErrors object, or the 567 dot3StatsFCSErrors object. 568 The precise meaning of the count represented by 569 an instance of this object is implementation- 570 specific. In particular, an instance of this 571 object may represent a count of receive errors 572 on a particular interface that are not 573 otherwise counted." 574 REFERENCE 575 "IEEE 802.3 Layer Management" 576 ::= { dot3StatsEntry 16 } 578 dot3StatsEtherChipSet OBJECT-TYPE 579 SYNTAX OBJECT IDENTIFIER 580 MAX-ACCESS read-only 581 STATUS current 582 DESCRIPTION 583 "This object contains an OBJECT IDENTIFIER 584 which identifies the chipset used to 585 realize the interface. Ethernet-like 586 interfaces are typically built out of 587 several different chips. The MIB implementor 588 is presented with a decision of which chip 589 to identify via this object. The implementor 590 should identify the chip which is usually 591 called the Medium Access Control chip. 592 If no such chip is easily identifiable, 593 the implementor should identify the chip 594 which actually gathers the transmit 595 and receive statistics and error 596 indications. This would allow a 597 manager station to correlate the 598 statistics and the chip generating 599 them, giving it the ability to take 600 into account any known anomalies 601 in the chip." 602 ::= { dot3StatsEntry 17 } 604 dot3StatsSymbolErrors OBJECT-TYPE 605 SYNTAX Counter32 606 MAX-ACCESS read-only 607 STATUS current 608 DESCRIPTION 609 "The number of times there was an invalid data symbol 610 when a valid carrier was present on a particular 611 interface. 613 The count represented by an instance of this 614 object is incremented at most once per 615 carrier event, even if multiple symbol 616 errors occur during the carrier event." 617 REFERENCE 618 "IEEE 802.3u-1995 10 & 100 Mb/s Management" 619 ::= { dot3StatsEntry 18 } 621 -- the Ethernet-like Collision Statistics group 623 -- Implementation of this group is optional; it is appropriate 624 -- for all systems which have the necessary metering 626 dot3CollTable OBJECT-TYPE 627 SYNTAX SEQUENCE OF Dot3CollEntry 628 MAX-ACCESS not-accessible 629 STATUS current 630 DESCRIPTION 631 "A collection of collision histograms for a 632 particular set of interfaces." 633 ::= { dot3 5 } 635 dot3CollEntry OBJECT-TYPE 636 SYNTAX Dot3CollEntry 637 MAX-ACCESS not-accessible 638 STATUS current 639 DESCRIPTION 640 "A cell in the histogram of per-frame 641 collisions for a particular interface. An 642 instance of this object represents the 643 frequency of individual MAC frames for which 644 the transmission (successful or otherwise) on a 645 particular interface is accompanied by a 646 particular number of media collisions." 647 INDEX { ifIndex, dot3CollCount } 648 ::= { dot3CollTable 1 } 650 Dot3CollEntry ::= SEQUENCE { 651 dot3CollCount INTEGER, 652 dot3CollFrequencies Counter32 653 } 655 -- { dot3CollEntry 1 } is no longer in use 657 dot3CollCount OBJECT-TYPE 658 SYNTAX INTEGER (1..16) 659 MAX-ACCESS not-accessible 660 STATUS current 661 DESCRIPTION 662 "The number of per-frame media collisions for 663 which a particular collision histogram cell 664 represents the frequency on a particular 665 interface." 666 ::= { dot3CollEntry 2 } 668 dot3CollFrequencies OBJECT-TYPE 669 SYNTAX Counter32 670 MAX-ACCESS read-only 671 STATUS current 672 DESCRIPTION 673 "A count of individual MAC frames for which the 674 transmission (successful or otherwise) on a 675 particular interface occurs after the 676 frame has experienced exactly the number 677 of collisions in the associated 678 dot3CollCount object. 680 For example, a frame which is transmitted 681 on interface 77 after experiencing 682 exactly 4 collisions would be indicated 683 by incrementing only dot3CollFrequencies.77.4. 684 No other instance of dot3CollFrequencies would 685 be incremented in this example." 686 ::= { dot3CollEntry 3 } 688 -- 802.3 Tests 690 dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } 692 dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } 694 -- TDR Test 696 -- The Time-Domain Reflectometry (TDR) test is specific 697 -- to ethernet-like interfaces with the exception of 698 -- 10BaseT and 10BaseF. The TDR value may be useful 699 -- in determining the approximate distance to a cable fault. 700 -- It is advisable to repeat this test to check for a 701 -- consistent resulting TDR value, to verify that there 702 -- is a fault. 704 dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 } 706 -- A TDR test returns as its result the time interval, 707 -- measured in 10 MHz ticks or 100 nsec units, between 708 -- the start of TDR test transmission and the subsequent 709 -- detection of a collision or deassertion of carrier. On 710 -- successful completion of a TDR test, the result is 711 -- stored as the value of the appropriate instance of the 712 -- MIB object dot3TestTdrValue, and the OBJECT IDENTIFIER 713 -- of that instanceis stored in the corresponding instance 714 -- of ifExtnsTestCode (thereby indicating where the 715 -- result has been stored). 717 -- Loopback Test 719 -- Another test is the full-duplex loopback test. 720 -- This test configures the MAC chip and executes 721 -- an internal loopback test of memory, data paths, 722 -- and the MAC chip logic. This loopback test can 723 -- only be executed if the interface is offline. 724 -- Once the test has completed, the MAC chip should 725 -- be reinitialized for network operation, but it 726 -- should remain offline. 728 dot3TestLoopBack OBJECT IDENTIFIER ::= { dot3Tests 2 } 730 -- If an error occurs during a test, the object 731 -- ifTestResult (defined in RFC1573) will be set 732 -- to failed(7). The following two OBJECT 733 -- IDENTIFIERs may be used to provided more 734 -- information as values for ifTestCode. 736 -- couldn't initialize MAC chip for test 737 dot3ErrorInitError OBJECT IDENTIFIER ::= { dot3Errors 1 } 739 -- expected data not received (or not 740 -- received correctly) in loopback test 741 dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 } 743 -- RFC1573 does away with the interface chipset object. 744 -- The following OBJECT IDENTIFIER definitions are 745 -- retained for purposes of backwards compatibility 746 -- with pre-RFC1573 systems. 747 -- 802.3 Hardware Chipsets 749 -- The object ifExtnsChipSet is provided in RFC1229 to 750 -- identify the MAC hardware used to communicate on an 751 -- interface. The following hardware chipsets are 752 -- provided for 802.3: 754 dot3ChipSets OBJECT IDENTIFIER ::= { dot3 8 } 755 dot3ChipSetAMD OBJECT IDENTIFIER ::= { dot3ChipSets 1 } 756 dot3ChipSetAMD7990 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 1 } 757 dot3ChipSetAMD79900 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 2 } 758 dot3ChipSetAMD79C940 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 3 } 760 dot3ChipSetIntel OBJECT IDENTIFIER ::= { dot3ChipSets 2 } 761 dot3ChipSetIntel82586 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 1 } 762 dot3ChipSetIntel82596 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 2 } 764 dot3ChipSetSeeq OBJECT IDENTIFIER ::= { dot3ChipSets 3 } 765 dot3ChipSetSeeq8003 OBJECT IDENTIFIER ::= { dot3ChipSetSeeq 1 } 767 dot3ChipSetNational OBJECT IDENTIFIER ::= { dot3ChipSets 4 } 768 dot3ChipSetNational8390 OBJECT IDENTIFIER ::= 769 { dot3ChipSetNational 1 } 770 dot3ChipSetNationalSonic OBJECT IDENTIFIER ::= 771 { dot3ChipSetNational 2 } 773 dot3ChipSetFujitsu OBJECT IDENTIFIER ::= { dot3ChipSets 5 } 774 dot3ChipSetFujitsu86950 OBJECT IDENTIFIER ::= 775 { dot3ChipSetFujitsu 1 } 777 dot3ChipSetDigital OBJECT IDENTIFIER ::= { dot3ChipSets 6 } 778 dot3ChipSetDigitalDC21040 OBJECT IDENTIFIER ::= 779 { dot3ChipSetDigital 1 } 781 -- For those chipsets not represented above, OBJECT IDENTIFIER 782 -- assignment is required in other documentation, e.g., assignment 783 -- within that part of the registration tree delegated to 784 -- individual enterprises (see RFC1155). 786 -- conformance information 788 etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 } 790 etherGroups OBJECT IDENTIFIER ::= { etherConformance 1 } 791 etherCompliances OBJECT IDENTIFIER ::= { etherConformance 2 } 793 -- compliance statements 795 etherCompliance MODULE-COMPLIANCE 796 STATUS current 797 DESCRIPTION 798 "The compliance statement for SNMPv2 entities which 799 have ethernet-like network interfaces." 801 MODULE -- this module 802 MANDATORY-GROUPS { etherStatsGroup } 804 GROUP etherCollisionTableGroup 805 DESCRIPTION 806 "This group is optional. It is appropriate for 807 all systems which have the necessary metering. 808 Implementation in such systems is highly 809 recommended." 810 ::= { etherCompliances 1 } 812 ether100MbsCompliance MODULE-COMPLIANCE 813 STATUS current 814 DESCRIPTION 815 "The compliance statement for SNMPv2 entities which 816 have 100 Mb/sec ethernet-like network interfaces." 818 MODULE -- this module 819 MANDATORY-GROUPS { etherStats100MbsGroup } 821 GROUP etherCollisionTableGroup 822 DESCRIPTION 823 "This group is optional. It is appropriate for 824 all systems which have the necessary metering. 825 Implementation in such systems is highly 826 recommended." 827 ::= { etherCompliances 2 } 829 -- units of conformance 831 etherStatsGroup OBJECT-GROUP 832 OBJECTS { dot3StatsIndex, dot3StatsAlignmentErrors, 833 dot3StatsFCSErrors, 834 dot3StatsSingleCollisionFrames, 835 dot3StatsMultipleCollisionFrames, 836 dot3StatsSQETestErrors, 837 dot3StatsDeferredTransmissions, 838 dot3StatsLateCollisions, 839 dot3StatsExcessiveCollisions, 840 dot3StatsInternalMacTransmitErrors, 841 dot3StatsCarrierSenseErrors, 842 dot3StatsFrameTooLongs, 843 dot3StatsInternalMacReceiveErrors, 844 dot3StatsEtherChipSet} 845 STATUS current 846 DESCRIPTION 847 "A collection of objects providing information 848 applicable to all ethernet-like network interfaces." 849 ::= { etherGroups 1 } 851 etherCollisionTableGroup OBJECT-GROUP 852 OBJECTS { dot3CollCount, dot3CollFrequencies } 853 STATUS current 854 DESCRIPTION 855 "A collection of objects providing a histogram 856 of packets successfully transmitted after 857 experiencing exactly N collisions." 858 ::= { etherGroups 2 } 860 etherStats100MbsGroup OBJECT-GROUP 861 OBJECTS { dot3StatsIndex, dot3StatsAlignmentErrors, 862 dot3StatsFCSErrors, 863 dot3StatsSingleCollisionFrames, 864 dot3StatsMultipleCollisionFrames, 865 dot3StatsDeferredTransmissions, 866 dot3StatsLateCollisions, 867 dot3StatsExcessiveCollisions, 868 dot3StatsInternalMacTransmitErrors, 869 dot3StatsCarrierSenseErrors, 870 dot3StatsFrameTooLongs, 871 dot3StatsInternalMacReceiveErrors, 872 dot3StatsEtherChipSet, 873 dot3StatsSymbolErrors} 874 STATUS current 875 DESCRIPTION 876 "A collection of objects providing information 877 applicable to 100 Mb/sec ethernet-like network 878 interfaces." 879 ::= { etherGroups 3 } 881 END 883 6. Acknowledgements 885 This document was produced by the 802.3 Hub MIB Working Group. 887 This document is almost completely based on both the Standard Ethernet 888 MIB, RFC 1623 [10], and the Proposed Standard Ethernet MIB using the 889 SNMPv2 SMI, RFC 1650 [11], both of which were edited by Frank Kastenholz 890 of FTP Software and produced by the Ethernet MIB Working Group. This 891 document extends those documents by providing support for 100 Mb/sec 892 ethernet interfaces as outlined in [6]. 894 RFC 1623 and RFC 1650, in turn, are based on the Draft Standard Ethernet 895 MIB, RFC 1398 [9], also edited by Frank Kastenholz and produced by the 896 Ethernet MIB Working Group. 898 RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB, RFC 899 1284 [8], which was editted by John Cook of Chipcom and produced by the 900 Transmission MIB Working Group. The Ethernet MIB Working Group gathered 901 implementation experience of the variables specified in RFC 1284 and 902 used that information to develop this revised MIB. 904 RFC 1284, in turn, is based on a document written by Frank Kastenholz, 905 then of Interlan, entitled IEEE 802.3 Layer Management Draft M 906 compatible MIB for TCP/IP Networks [7]. This document has been modestly 907 reworked, initially by the SNMP Working Group, and then by the 908 Transmission Working Group, to reflect the current conventions for 909 defining objects for MIB interfaces. James Davin, of the MIT Laboratory 910 for Computer Science, and Keith McCloghrie of Hughes LAN Systems, 911 contributed to later drafts of this memo. Marshall Rose of Performance 912 Systems International, Inc. converted the document into its current 913 concise format. Anil Rijsinghani of DEC contributed text that more 914 adequately describes the TDR test. Thanks to Frank Kastenholz of 915 Interlan and Louis Steinberg of IBM for their experimentation. 917 7. References 919 [1] Information processing systems - Open Systems Interconnection - 920 Specification of Abstract Syntax Notation One (ASN.1), 921 International Organization for Standardization, International 922 Standard 8824, December 1987. 924 [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 925 S. Waldbusser, "Structure of Management Information for Version 2 926 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 927 January 1996. 929 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 930 S. Waldbusser, "Textual Conventions for Version 2 of the Simple 931 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 933 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 934 S. Waldbusser, "Conformance Statements for Version 2 of the 935 Simple Network Management Protocol (SNMPv2)", RFC 1904, 936 January 1996. 938 [5] IEEE, IEEE 802.3 Layer Management, November 1988. 940 [6] IEEE, IEEE 802.3u-1995, "10 & 100 Mb/s Management," Section 30, 941 Supplement to IEEE Std 802.3, October 26, 1995. 943 [7] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible MIB 944 for TCP/IP Networks", electronic mail message to mib- 945 wg@nnsc.nsf.net, 9 June 1989. 947 [8] Cook, J., "Definitions of Managed Objects for Ethernet-Like 948 Interface Types", RFC 1284, Chipcom Corporation, December 1991. 950 [9] Kastenholz, F., "Definitions of Managed Objects for the 951 Ethernet-like Interface Types", RFC 1398, FTP Software, Inc., 952 January 1993. 954 [10] Kastenholz, F., "Definitions of Managed Objects for the 955 Ethernet-like Interface Types", RFC 1623, FTP Software, Inc., 956 May 1994. 958 [11] Kastenholz, F., "Definitions of Managed Objects for the 959 Ethernet-like Interface Types using SMIv2", RFC 1650, 960 FTP Software, Inc., August 1994. 962 [12] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces 963 Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, 964 January 1994. 966 8. Security Considerations 968 Security issues are not discussed in this memo. 970 9. Author's Addresses 972 Jeffrey Johnson 973 cisco Systems, Inc. 974 170 W.Tasman Drive 975 San Jose, CA, 94015, USA 977 Phone: +1-408-526-7789 978 EMail: jjohnson@cisco.com