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