idnits 2.17.1 draft-ietf-ethermib-objectsv2-02.txt: ** The Abstract section seems to be numbered 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 112 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 711 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (13 August 1992) is 11579 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) -- Missing reference section? '7' on line 817 looks like a reference -- Missing reference section? '3' on line 794 looks like a reference -- Missing reference section? '8' on line 823 looks like a reference -- Missing reference section? '13' on line 846 looks like a reference -- Missing reference section? '6' on line 812 looks like a reference -- Missing reference section? '9' on line 829 looks like a reference -- Missing reference section? '10' on line 831 looks like a reference -- Missing reference section? '11' on line 836 looks like a reference -- Missing reference section? '14' on line 853 looks like a reference -- Missing reference section? '1' on line 787 looks like a reference -- Missing reference section? '2' on line 791 looks like a reference -- Missing reference section? '4' on line 799 looks like a reference -- Missing reference section? '5' on line 806 looks like a reference -- Missing reference section? '12' on line 841 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 4 Definitions of Managed Objects for 5 the Ethernet-like Interface Types 7 13 August 1992 9 Ethernet MIB Working Group 10 Frank Kastenholz 11 FTP Software, Inc 12 26 Princess Street 13 Wakefield, Mass 01880 USA 15 kasten@ftp.com 17 Status of this Memo 19 This document is an Internet Draft. Internet Drafts are 20 working documents of the Internet Engineering Task Force 21 (IETF), its Areas, and its Working Groups. Note that other 22 groups may also distribute working documents as Internet 23 Drafts. 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or 27 obsoleted by other documents at any time. It is not 28 appropriate to use Internet Drafts as reference material or to 29 cite them other than as a ``working draft'' or ``work in 30 progress.'' Please check the 1id-abstracts.txt listing 31 contained in the internet-drafts Shadow Directories on 32 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or 33 munnari.oz.au to learn the current status of any Internet 34 Draft. 36 Internet Draft Ethernet-Like MIB August 1992 38 This document will be submitted to the Internet Activities 39 Board as a Draft Standard. This document defines an 40 experimental extension to the SNMP MIB. Upon publication as a 41 Draft Standard, a new MIB number will be assigned. This is a 42 working document only, it should neither be cited nor quoted 43 in any formal document. 45 This document will expire before 18 Feb. 1993. 47 Distribution of this document is unlimited. 49 Please send comments to the author. 51 Internet Draft Ethernet-Like MIB August 1992 53 1. Abstract 55 This memo defines a portion of the Management Information Base 56 (MIB) for use with network management protocols in TCP/IP- 57 based internets. In particular, it defines objects for 58 managing ethernet-like objects. 60 This memo does not specify a standard for the Internet 61 Community. 63 2. Change Log 65 (1) Replace old "Historical Perspective" boilerplate with the 66 new "The Network Management Framework" boilerplate. 68 (2) Remove the "slime text". 70 (3) Updated the reference to the Interface Extensions mib to 71 reflect its new RFC status. 73 (4) Change the status of the memo section to hold the new 74 suggested text. 76 (5) References in ASN.1 comments were changed from the [#] 77 form to name the actual document being referred to. These 78 references are now meaningful when the ASN.1 is read 79 outside of the RFC. 81 (6) The IMPORTS section of the ASN.1 has been updated to 82 reflect that the OBJECT-TYPE macro is imported from RFC- 83 1212. 85 (7) The the Generic Ethernet-like group, containing 86 dot3Index, dot3InitializeMac, dot3MacSubLayerStatus, 87 dot3MulticastReceiveStatus, dot3TxEnabled, and 88 dot3TestTdrValue has been deprecated as a result of the 89 implementation experience presented at the San Diego IETF 90 meeting. 92 (8) dot3StatsInRangeLengthErrors and 93 dot3StatsOutOfRangeLengthFields have been deprecated as a 94 result of the implementation experience presented at the 95 San Diego IETF meeting. 97 Internet Draft Ethernet-Like MIB August 1992 99 (9) Update the acknowledgements section to reflect this 100 document's history, etc. 102 (10) REFERENCE clauses have been added to all of the MIB 103 objects which are being retained. 105 12 August 1992 107 (1) Removed all deprecated objects. 109 (2) Rephrased the description of the TDR test OID to reflect 110 the fact that dot3TestTdrValue is no more. 111 ifExtnsTestResult still points to the object containing 112 the result, the text simply does not refer to 113 dot3TestTdrValue. I could have deleted the Test, but the 114 OID should then remain reserved. I figured that it would 115 be just as easy to rephrase the definition of the test. 117 13 august 1992 119 (1) Add fuji. 86960 121 3. The Network Management Framework 123 The Internet-standard Network Management Framework consists of 124 three components. They are: 126 RFC 1155 which defines the SMI, the mechanisms used for 127 describing and naming objects for the purpose of 128 management. RFC 1212 defines a more concise description 129 mechanism, which is wholly consistent with the SMI. 131 RFC 1156 which defines MIB-I, the core set of managed 132 objects for the Internet suite of protocols. RFC 1213, 133 defines MIB-II, an evolution of MIB-I based on 134 implementation experience and new operational 135 requirements. 137 RFC 1157 which defines the SNMP, the protocol used for 138 network access to managed objects. 140 The Framework permits new objects to be defined for the 141 purpose of experimentation and evaluation. 143 Internet Draft Ethernet-Like MIB August 1992 145 4. Objects 147 Managed objects are accessed via a virtual information store, 148 termed the Management Information Base or MIB. Objects in the 149 MIB are defined using the subset of Abstract Syntax Notation 150 One (ASN.1) [7] defined in the SMI. In particular, each 151 object has a name, a syntax, and an encoding. The name is an 152 object identifier, an administratively assigned name, which 153 specifies an object type. The object type together with an 154 object instance serves to uniquely identify a specific 155 instantiation of the object. For human convenience, we often 156 use a textual string, termed the OBJECT DESCRIPTOR, to also 157 refer to the object type. 159 The syntax of an object type defines the abstract data 160 structure corresponding to that object type. The ASN.1 161 language is used for this purpose. However, the SMI [3] 162 purposely restricts the ASN.1 constructs which may be used. 163 These restrictions are explicitly made for simplicity. 165 The encoding of an object type is simply how that object type 166 is represented using the object type's syntax. Implicitly 167 tied to the notion of an object type's syntax and encoding is 168 how the object type is represented when being transmitted on 169 the network. 171 The SMI specifies the use of the basic encoding rules of ASN.1 172 [8], subject to the additional requirements imposed by the 173 SNMP. 175 4.1. Format of Definitions 177 Section 5 contains contains the specification of all object 178 types contained in this MIB module. The object types are 179 defined using the conventions defined in the SMI, as amended 180 by the extensions specified in [13]. 182 5. Overview 184 Instances of these object types represent attributes of an 185 interface to an ethernet-like communications medium. At 186 present, ethernet-like media are identified by three values of 188 Internet Draft Ethernet-Like MIB August 1992 190 the ifType object in the Internet-standard MIB: 192 ethernet-csmacd(6) 193 iso88023-csmacd(7) 194 starLan(11) 196 For these interfaces, the value of the ifSpecific variable in 197 the MIB-II [6] has the OBJECT IDENTIFIER value: 199 dot3 OBJECT IDENTIFER ::= { experimental 3 } 201 The definitions presented here are based on the IEEE 802.3 202 Layer Management Specification [9], as originally interpreted 203 by Frank Kastenholz of Interlan in [10]. Implementors of 204 these MIB objects should note that the IEEE document 205 explicitly describes (in the form of Pascal pseudocode) when, 206 where, and how various MAC attributes are measured. The IEEE 207 document also describes the effects of MAC actions that may be 208 invoked by manipulating instances of the MIB objects defined 209 here. 211 To the extent that some of the attributes defined in [9] are 212 represented by previously defined objects in the Internet- 213 standard MIB or in the Generic Interface Extensions MIB [11], 214 such attributes are not redundantly represented by objects 215 defined in this memo. Among the attributes represented by 216 objects defined in other memos are the number of octets 217 transmitted or received on a particular interface, the number 218 of frames transmitted or received on a particular interface, 219 the promiscuous status of an interface, the MAC address of an 220 interface, and multicast information associated with an 221 interface. 223 The relationship between an ethernet-like interface and an 224 interface in the context of the Internet-standard MIB is one- 225 to-one. As such, the value of an ifIndex object instance can 226 be directly used to identify corresponding instances of the 227 objects defined herein. 229 6. Definitions 231 RFCxxx-MIB DEFINITIONS ::= BEGIN 233 Internet Draft Ethernet-Like MIB August 1992 235 IMPORTS 236 experimental, Counter, Gauge 237 FROM RFC1155-SMI 238 OBJECT-TYPE 239 FROM RFC-1212; 241 -- This MIB module uses the extended OBJECT-TYPE macro as 242 -- defined in RFC-1212. 244 -- this is the MIB module for ethernet-like objects 246 dot3 OBJECT IDENTIFIER ::= { experimental 3 } 247 -- { dot3 1 } is obsolete and has been deleted. 249 Internet Draft Ethernet-Like MIB August 1992 251 6.1. The Ethernet-like Statistics Group 253 -- the Ethernet-like Statistics group 255 -- Implementation of this group is mandatory 257 dot3StatsTable OBJECT-TYPE 258 SYNTAX SEQUENCE OF Dot3StatsEntry 259 ACCESS not-accessible 260 STATUS mandatory 261 DESCRIPTION 262 "Statistics for a collection of ethernet-like 263 interfaces attached to a particular system." 264 ::= { dot3 2 } 266 dot3StatsEntry OBJECT-TYPE 267 SYNTAX Dot3StatsEntry 268 ACCESS not-accessible 269 STATUS mandatory 270 DESCRIPTION 271 "Statistics for a particular interface to an 272 ethernet-like medium." 273 INDEX { dot3StatsIndex } 274 ::= { dot3StatsTable 1 } 276 Dot3StatsEntry ::= SEQUENCE { 277 dot3StatsIndex 278 INTEGER, 279 dot3StatsAlignmentErrors 280 Counter, 281 dot3StatsFCSErrors 282 Counter, 283 dot3StatsSingleCollisionFrames 284 Counter, 285 dot3StatsMultipleCollisionFrames 286 Counter, 287 dot3StatsSQETestErrors 288 Counter, 289 dot3StatsDeferredTransmissions 290 Counter, 292 Internet Draft Ethernet-Like MIB August 1992 294 dot3StatsLateCollisions 295 Counter, 296 dot3StatsExcessiveCollisions 297 Counter, 298 dot3StatsInternalMacTransmitErrors 299 Counter, 300 dot3StatsCarrierSenseErrors 301 Counter, 302 dot3StatsFrameTooLongs 303 Counter, 304 dot3StatsInternalMacReceiveErrors 305 Counter 306 } 308 dot3StatsIndex OBJECT-TYPE 309 SYNTAX INTEGER 310 ACCESS read-only 311 STATUS mandatory 312 DESCRIPTION 313 "An index value that uniquely identifies an 314 interface to an ethernet-like medium. The 315 interface identified by a particular value of 316 this index is the same interface as identified 317 by the same value of ifIndex." 318 ::= { dot3StatsEntry 1 } 320 dot3StatsAlignmentErrors OBJECT-TYPE 321 SYNTAX Counter 322 ACCESS read-only 323 STATUS mandatory 324 DESCRIPTION 325 "A count of frames received on a particular 326 interface that are not an integral number of 327 octets in length and do not pass the FCS check. 329 The count represented by an instance of this 330 object is incremented when the alignmentError 331 status is returned by the MAC service to the 332 LLC (or other MAC user). Received frames for 333 which multiple error conditions obtain are, 334 according to the conventions of IEEE 802.3 335 Layer Management, counted exclusively according 336 to the error status presented to the LLC." 338 Internet Draft Ethernet-Like MIB August 1992 340 REFERENCE 341 "IEEE 802.3 Layer Management" 342 ::= { dot3StatsEntry 2 } 344 dot3StatsFCSErrors OBJECT-TYPE 345 SYNTAX Counter 346 ACCESS read-only 347 STATUS mandatory 348 DESCRIPTION 349 "A count of frames received on a particular 350 interface that are an integral number of octets 351 in length but do not pass the FCS check. 353 The count represented by an instance of this 354 object is incremented when the frameCheckError 355 status is returned by the MAC service to the 356 LLC (or other MAC user). Received frames for 357 which multiple error conditions obtain are, 358 according to the conventions of IEEE 802.3 359 Layer Management, counted exclusively according 360 to the error status presented to the LLC." 361 REFERENCE 362 "IEEE 802.3 Layer Management" 363 ::= { dot3StatsEntry 3 } 365 dot3StatsSingleCollisionFrames OBJECT-TYPE 366 SYNTAX Counter 367 ACCESS read-only 368 STATUS mandatory 369 DESCRIPTION 370 "A count of successfully transmitted frames on 371 a particular interface for which transmission 372 is inhibited by exactly one collision. 374 A frame that is counted by an instance of this 375 object is also counted by the corresponding 376 instance of either the ifOutUcastPkts or 377 ifOutNUcastPkts object and is not counted by 378 the corresponding instance of the 379 dot3StatsMultipleCollisionFrames object." 380 REFERENCE 381 "IEEE 802.3 Layer Management" 383 Internet Draft Ethernet-Like MIB August 1992 385 ::= { dot3StatsEntry 4 } 387 dot3StatsMultipleCollisionFrames OBJECT-TYPE 388 SYNTAX Counter 389 ACCESS read-only 390 STATUS mandatory 391 DESCRIPTION 392 "A count of successfully transmitted frames on 393 a particular interface for which transmission 394 is inhibited by more than one collision. 396 A frame that is counted by an instance of this 397 object is also counted by the corresponding 398 instance of either the ifOutUcastPkts or 399 ifOutNUcastPkts object and is not counted by 400 the corresponding instance of the 401 dot3StatsSingleCollisionFrames object." 402 REFERENCE 403 "IEEE 802.3 Layer Management" 404 ::= { dot3StatsEntry 5 } 406 dot3StatsSQETestErrors OBJECT-TYPE 407 SYNTAX Counter 408 ACCESS read-only 409 STATUS mandatory 410 DESCRIPTION 411 "A count of times that the SQE TEST ERROR 412 message is generated by the PLS sublayer for a 413 particular interface. The SQE TEST ERROR 414 message is defined in section 7.2.2.2.4 of 415 ANSI/IEEE 802.3-1985 and its generation is 416 described in section 7.2.4.6 of the same 417 document." 418 REFERENCE 419 "ANSI/IEEE Std 802.3-1985 Carrier Sense 420 Multiple Access with Collision Detection Access 421 Method and Physical Layer Specifications" 422 ::= { dot3StatsEntry 6 } 424 dot3StatsDeferredTransmissions OBJECT-TYPE 425 SYNTAX Counter 427 Internet Draft Ethernet-Like MIB August 1992 429 ACCESS read-only 430 STATUS mandatory 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 Counter 445 ACCESS read-only 446 STATUS mandatory 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 Counter 466 ACCESS read-only 467 STATUS mandatory 468 DESCRIPTION 469 "A count of frames for which transmission on a 470 particular interface fails due to excessive 472 Internet Draft Ethernet-Like MIB August 1992 474 collisions." 475 REFERENCE 476 "IEEE 802.3 Layer Management" 477 ::= { dot3StatsEntry 9 } 479 dot3StatsInternalMacTransmitErrors OBJECT-TYPE 480 SYNTAX Counter 481 ACCESS read-only 482 STATUS mandatory 483 DESCRIPTION 484 "A count of frames for which transmission on a 485 particular interface fails due to an internal 486 MAC sublayer transmit error. A frame is only 487 counted by an instance of this object if it is 488 not counted by the corresponding instance of 489 either the dot3StatsLateCollisions object, the 490 dot3StatsExcessiveCollisions object, or the 491 dot3StatsCarrierSenseErrors object. 493 The precise meaning of the count represented by 494 an instance of this object is implementation- 495 specific. In particular, an instance of this 496 object may represent a count of transmission 497 errors on a particular interface that are not 498 otherwise counted." 499 REFERENCE 500 "IEEE 802.3 Layer Management" 501 ::= { dot3StatsEntry 10 } 503 dot3StatsCarrierSenseErrors OBJECT-TYPE 504 SYNTAX Counter 505 ACCESS read-only 506 STATUS mandatory 507 DESCRIPTION 508 "The number of times that the carrier sense 509 condition was lost or never asserted when 510 attempting to transmit a frame on a particular 511 interface. 513 The count represented by an instance of this 514 object is incremented at most once per 515 transmission attempt, even if the carrier sense 517 Internet Draft Ethernet-Like MIB August 1992 519 condition fluctuates during a transmission 520 attempt." 521 REFERENCE 522 "IEEE 802.3 Layer Management" 523 ::= { dot3StatsEntry 11 } 525 -- { dot3StatsEntry 12 } is not assigned 527 dot3StatsFrameTooLongs OBJECT-TYPE 528 SYNTAX Counter 529 ACCESS read-only 530 STATUS mandatory 531 DESCRIPTION 532 "A count of frames received on a particular 533 interface that exceed the maximum permitted 534 frame size. 536 The count represented by an instance of this 537 object is incremented when the frameTooLong 538 status is returned by the MAC service to the 539 LLC (or other MAC user). Received frames for 540 which multiple error conditions obtain are, 541 according to the conventions of IEEE 802.3 542 Layer Management, counted exclusively according 543 to the error status presented to the LLC." 544 REFERENCE 545 "IEEE 802.3 Layer Management" 546 ::= { dot3StatsEntry 13 } 548 -- { dot3StatsEntry 14 } is not assigned 550 -- { dot3StatsEntry 15 } is not assigned 552 dot3StatsInternalMacReceiveErrors OBJECT-TYPE 553 SYNTAX Counter 554 ACCESS read-only 555 STATUS mandatory 556 DESCRIPTION 557 "A count of frames for which reception on a 559 Internet Draft Ethernet-Like MIB August 1992 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. 569 The precise meaning of the count represented by 570 an instance of this object is implementation- 571 specific. In particular, an instance of this 572 object may represent a count of receive errors 573 on a particular interface that are not 574 otherwise counted." 575 REFERENCE 576 "IEEE 802.3 Layer Management" 577 ::= { dot3StatsEntry 16 } 579 Internet Draft Ethernet-Like MIB August 1992 581 6.2. The Ethernet-like Collision Statistics Group 583 -- the Ethernet-like Collision Statistics group 585 -- Implementation of this group is optional; it is appropriate 586 -- for all systems which have the necessary metering 588 dot3CollTable OBJECT-TYPE 589 SYNTAX SEQUENCE OF Dot3CollEntry 590 ACCESS not-accessible 591 STATUS mandatory 592 DESCRIPTION 593 "A collection of collision histograms for a 594 particular set of interfaces." 595 ::= { dot3 5 } 597 dot3CollEntry OBJECT-TYPE 598 SYNTAX Dot3CollEntry 599 ACCESS not-accessible 600 STATUS mandatory 601 DESCRIPTION 602 "A cell in the histogram of per-frame 603 collisions for a particular interface. An 604 instance of this object represents the 605 frequency of individual MAC frames for which 606 the transmission (successful or otherwise) on a 607 particular interface is accompanied by a 608 particular number of media collisions." 609 INDEX { dot3CollIndex, dot3CollCount } 610 ::= { dot3CollTable 1 } 612 Dot3CollEntry ::= SEQUENCE { 613 dot3CollIndex 614 INTEGER, 615 dot3CollCount 616 INTEGER, 617 dot3CollFrequencies 618 Counter 619 } 621 Internet Draft Ethernet-Like MIB August 1992 623 dot3CollIndex OBJECT-TYPE 624 SYNTAX INTEGER 625 ACCESS read-only 626 STATUS mandatory 627 DESCRIPTION 628 "The index value that uniquely identifies the 629 interface to which a particular collision 630 histogram cell pertains. The interface 631 identified by a particular value of this index 632 is the same interface as identified by the same 633 value of ifIndex." 634 ::= { dot3CollEntry 1 } 636 dot3CollCount OBJECT-TYPE 637 SYNTAX INTEGER (1..16) 638 ACCESS read-only 639 STATUS mandatory 640 DESCRIPTION 641 "The number of per-frame media collisions for 642 which a particular collision histogram cell 643 represents the frequency on a particular 644 interface." 645 ::= { dot3CollEntry 2 } 647 dot3CollFrequencies OBJECT-TYPE 648 SYNTAX Counter 649 ACCESS read-only 650 STATUS mandatory 651 DESCRIPTION 652 "A count of individual MAC frames for which the 653 transmission (successful or otherwise) on a 654 particular interface is accompanied by a 655 particular number of media collisions." 656 ::= { dot3CollEntry 3 } 658 Internet Draft Ethernet-Like MIB August 1992 660 6.3. 802.3 Tests 662 -- 802.3 Tests 664 -- The ifExtnsTestTable defined in RFC1229 provides a common means 665 -- for a manager to test any interface corresponding to a value 666 -- of ifIndex. 668 -- At this time, one well known test (testFullDuplexLoopBack) is 669 -- defined in RFC1229. For ethernet-like interfaces, this test 670 -- configures the MAC chip and executes an internal loopback 671 -- test of memory and the MAC chip logic. This loopback test can 672 -- only be executed if the interface is offline. Once the test 673 -- has completed, the MAC chip should be reinitialized for network 674 -- operation, but it should remain offline. 676 -- If an error occurs during a test, the object ifExtnsTestResult 677 -- (defined in RFC1229) will be set to failed(7). The following two 678 -- OBJECT IDENTIFIERs may be used to provided more information as 679 -- values for the object ifExtnsTestCode in RFC1229: 681 dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } 683 -- couldn't initialize MAC chip for test 684 dot3ErrorInitError OBJECT IDENTIFIER ::= { dot3Errors 1 } 686 -- expected data not received (or not 687 -- received correctly) in loopback test 688 dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 } 690 -- Tests 691 -- TDR Test 693 -- Another test, specific to ethernet-like interfaces with the 694 -- exception of 10BaseT and 10BaseF, is Time-domain Reflectometry 695 (TDR). 696 -- The TDR value may be useful in determining the approximate 697 distance 698 -- to a cable fault. It is advisable to repeat this test to check 699 for 700 -- a consistent resulting TDR value, to verify that there is a 701 fault. 703 dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } 704 dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 } 706 -- A TDR test returns as its result the time interval, measured 708 Internet Draft Ethernet-Like MIB August 1992 710 -- in 10 MHz ticks or 100 nsec units, between the start of 711 -- TDR test transmission and the subsequent detection of a 712 -- collision or deassertion of carrier. On successful completion 713 -- of a TDR test, the appropriate instance of ifExtnsTestResult 714 -- contains the OBJECT IDENTIFIER of the MIB object which contains 715 -- the value of this time interval. 717 Internet Draft Ethernet-Like MIB August 1992 719 6.4. 802.3 Hardware Chipsets 721 -- 802.3 Hardware Chipsets 723 -- The object ifExtnsChipSet is provided in RFC1229 to identify the 724 -- MAC hardware used to communcate on an interface. The following 725 -- hardware chipsets are provided for 802.3: 727 dot3ChipSets OBJECT IDENTIFIER ::= { dot3 8 } 728 dot3ChipSetAMD OBJECT IDENTIFIER ::= { dot3ChipSets 1 } 729 dot3ChipSetAMD7990 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 1 } 730 dot3ChipSetAMD79900 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 2 } 732 dot3ChipSetIntel OBJECT IDENTIFIER ::= { dot3ChipSets 2 } 733 dot3ChipSetIntel82586 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 1 } 734 dot3ChipSetIntel82596 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 2 } 736 dot3ChipSetSeeq OBJECT IDENTIFIER ::= { dot3ChipSets 3 } 737 dot3ChipSetSeeq8003 OBJECT IDENTIFIER ::= { dot3ChipSetSeeq 1 } 739 dot3ChipSetNational OBJECT IDENTIFIER ::= { dot3ChipSets 4 } 740 dot3ChipSetNational8390 OBJECT IDENTIFIER ::= 741 { dot3ChipSetNational 1 } 742 dot3ChipSetNationalSonic OBJECT IDENTIFIER ::= 743 { dot3ChipSetNational 2 } 745 dot3ChipSetFujitsu OBJECT IDENTIFIER ::= { dot3ChipSets 5 } 746 dot3ChipSetFujitsu86950 OBJECT IDENTIFIER ::= 747 { dot3ChipSetFujitsu 1 } 748 dot3ChipSetFujitsu86960 OBJECT IDENTIFIER ::= 749 { dot3ChipSetFujitsu 2 } 751 -- For those chipsets not represented above, OBJECT IDENTIFIER 752 -- assignment is required in other documentation, e.g., assignment 753 -- within that part of the registration tree delegated to 754 -- individual enterprises (see RFC1155). 756 END 758 Internet Draft Ethernet-Like MIB August 1992 760 7. Acknowledgements 762 This document was produced by the Ethernet MIB Working Group. 764 This document is based on the Proposed Standard Ethernet MIB, 765 RFC-1284[14], of which Jihn Cook of Chipcom was the editor. 766 The Ethernet MIB Working Group gathered implementation 767 experience of the variables specified in RFC-1284 and used 768 that information to develop this revised MIB. 770 RFC-1284, in turn, is based on a document written by Frank 771 Kastenholz of Interlan entitled IEEE 802.3 Layer Management 772 Draft M compatible MIB for TCP/IP Networks [10]. This 773 document has been modestly reworked, initially by the SNMP 774 Working Group, and then by the Transmission Working Group, to 775 reflect the current conventions for defining objects for MIB 776 interfaces. James Davin, of the MIT Laboratory for Computer 777 Science, and Keith McCloghrie of Hughes LAN Systems, 778 contributed to later drafts of this memo. Marshall Rose of 779 Performance Systems International, Inc. converted the document 780 into its current concise format. Anil Rijsinghani of DEC 781 contributed text that more adequately describes the TDR test. 782 Thanks to Frank Kastenholz of Interlan and Louis Steinberg of 783 IBM for their experimentation. 785 8. References 787 [1] Cerf, V., IAB Recommendations for the Development of 788 Internet Network Management Standards, RFC 1052, NRI, 789 April 1988. 791 [2] Cerf, V., Report of the Second Ad Hoc Network Management 792 Review Group, RFC 1109, NRI, August 1989. 794 [3] Rose M., and K. McCloghrie, Structure and Identification 795 of Management Information for TCP/IP-based internets, RFC 796 1155, Performance Systems International, Hughes LAN 797 Systems, May 1990. 799 [4] McCloghrie K., and M. Rose, Management Information Base 800 for Network Management of TCP/IP-based internets, RFC 801 1156, Hughes LAN Systems, Performance Systems 802 International, May 1990. 804 Internet Draft Ethernet-Like MIB August 1992 806 [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 807 Simple Network Management Protocol, RFC 1157, SNMP 808 Research, Performance Systems International, Performance 809 Systems International, MIT Laboratory for Computer 810 Science, May 1990. 812 [6] McCloghrie K., and M. Rose, Editors, Management 813 Information Base for Network Management of TCP/IP-based 814 internets, RFC 1213, Performance Systems International, 815 March 1991. 817 [7] Information processing systems - Open Systems 818 Interconnection - Specification of Abstract Syntax 819 Notation One (ASN.1), International Organization for 820 Standardization, International Standard 8824, December 821 1987. 823 [8] Information processing systems - Open Systems 824 Interconnection - Specification of Basic Encoding Rules 825 for Abstract Notation One (ASN.1), International 826 Organization for Standardization, International Standard 827 8825, December 1987. 829 [9] IEEE, IEEE 802.3 Layer Management, November 1988. 831 [10] 832 Kastenholz, F., IEEE 802.3 Layer Management Draft 833 compatible MIB for TCP/IP Networks, electronic mail 834 message to mib-wg@nnsc.nsf.net, 9 June 1989. 836 [11] 837 McCloghrie, K., Editor, Extensions to the Generic- 838 Interface MIB, RFC 1229, Hughes LAN Systems, Inc., May 839 1991. 841 [12] 842 IEEE, Carrier Sense Multiple Access with Collision 843 Detection (CSMA/CD) Access Method and Physical Layer 844 Specifications, ANSI/IEEE Std 802.3-1985. 846 [13] 847 Rose, M., and K. McCloghrie, Editors, Concise MIB 848 Definitions, RFC 1212, Performance Systems International, 849 Hughes LAN Systems, March 1991. 851 Internet Draft Ethernet-Like MIB August 1992 853 [14] 854 Cook, J., Definitions of Managed Objects for Ethernet- 855 Like Interface Types, RFC1284, Decepmber 1991. 857 9. Security Considerations 859 Security issues are not discussed in this memo. 861 10. Author's Address 863 Frank Kastenholz 864 FTP Software, Inc. 865 26 Princess Street 866 Wakefield Mass 01748 868 Phone: 617-246-0900 869 EMail: kasten@ftp.com 871 Internet Draft Ethernet-Like MIB August 1992 873 Table of Contents 875 Status of this Memo .................................... 1 876 1 Abstract .............................................. 3 877 2 Change Log ............................................ 3 878 3 The Network Management Framework ...................... 4 879 4 Objects ............................................... 5 880 4.1 Format of Definitions ............................... 5 881 5 Overview .............................................. 5 882 6 Definitions ........................................... 6 883 6.1 The Ethernet-like Statistics Group .................. 8 884 6.2 The Ethernet-like Collision Statistics Group ........ 16 885 6.3 802.3 Tests ......................................... 18 886 6.4 802.3 Hardware Chipsets ............................. 20 887 7 Acknowledgements ...................................... 21 888 8 References ............................................ 21 889 9 Security Considerations ............................... 23 890 10 Author's Address ..................................... 23