idnits 2.17.1 draft-ietf-snmp-ethernetmib-05.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-25) 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Abstract' ) ** 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 39 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (April 1991) is 12064 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? '1' on line 925 looks like a reference -- Missing reference section? '2' on line 931 looks like a reference -- Missing reference section? '3' on line 936 looks like a reference -- Missing reference section? '4' on line 942 looks like a reference -- Missing reference section? '5' on line 948 looks like a reference -- Missing reference section? '7' on line 960 looks like a reference -- Missing reference section? '8' on line 966 looks like a reference -- Missing reference section? '13' on line 985 looks like a reference -- Missing reference section? '6' on line 954 looks like a reference -- Missing reference section? '9' on line 972 looks like a reference -- Missing reference section? '10' on line 974 looks like a reference -- Missing reference section? '11' on line 978 looks like a reference -- Missing reference section? '12' on line 981 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft ETHERNET-LIKE OBJECTS April 1991 4 Definitions of Managed Objects 5 for the Ethernet-like Interface Types 7 7 April 1991 9 Transmission MIB Working Group 10 J. Cook (editor) 12 Chipcom Corporation 13 118 Turnpike Road 14 Southborough, MA 01772 16 cook@chipcom.com 18 1. Status of this Memo 20 This draft document will be submitted to the RFC editor as an 21 experimental extension to the SNMP MIB. Distribution of this 22 memo is unlimited. Please send comments to cook@chipcom.com 23 and kzm@hls.com. 25 2. Abstract 27 This memo defines an experimental portion of the Management 28 Information Base (MIB) for use with network management 29 protocols in TCP/IP-based internets. In particular, it 30 defines objects for managing ethernet-like objects. 32 This memo does not specify a standard for the Internet 33 community. 35 3. Historical Perspective 37 As reported in RFC 1052, IAB Recommendations for the 38 Development of Internet Network Management Standards [1], a 39 two-prong strategy for network management of TCP/IP-based 40 internets was undertaken. In the short-term, the Simple 41 Network Management Protocol (SNMP), defined in RFC 1067, was 42 to be used to manage nodes in the Internet community. In the 43 long-term, the use of the OSI network management framework was 44 to be examined. Two documents were produced to define the 45 management information: RFC 1065, which defined the Structure 46 of Management Information (SMI), and RFC 1066, which defined 47 the Management Information Base (MIB). Both of these 48 documents were designed so as to be compatible with both the 49 SNMP and the OSI network management framework. 51 This strategy was quite successful in the short-term: 52 Internet-based network management technology was fielded, by 53 both the research and commercial communities, within a few 54 months. As a result of this, portions of the Internet 55 community became network manageable in a timely fashion. 57 As reported in RFC 1109, Report of the Second Ad Hoc Network 58 Management Review Group [2], the requirements of the SNMP and 59 the OSI network management frameworks were more different than 60 anticipated. As such, the requirement for compatibility 61 between the SMI/MIB and both frameworks was suspended. This 62 action permitted the operational network management framework, 63 based on the SNMP, to respond to new operational needs in the 64 Internet community by producing MIB-II. 66 In May of 1990, the core documents were elevated to "Standard 67 Protocols" with "Recommended" status. As such, the Internet- 68 standard network management framework consists of: Structure 69 and Identification of Management Information for TCP/IP-based 70 internets, RFC 1155 [3], which describes how managed objects 71 contained in the MIB are defined; Management Information Base 72 for Network Management of TCP/IP-based internets, which 73 describes the managed objects contained in the MIB, RFC 1156 74 [4]; and, the Simple Network Management Protocol, RFC 1157 75 [5], which defines the protocol used to manage these objects. 77 Consistent with the IAB directive to produce simple, workable 78 systems in the short-term, the list of managed objects defined 79 in the Internet-standard MIB was derived by taking only those 80 elements which are considered essential. However, the SMI 81 defined three extensibility mechanisms: one, the addition of 82 new standard objects through the definitions of new versions 83 of the MIB; two, the addition of widely-available but non- 84 standard objects through the experimental subtree; and three, 85 the addition of private objects through the enterprises 86 subtree. Such additional objects can not only be used for 87 vendor-specific elements, but also for experimentation as 88 required to further the knowledge of which other objects are 89 essential. 91 This memo defines extensions to the MIB using the second 92 method. It contains definitions of managed objects used for 93 experimentation. 95 4. Objects 97 Managed objects are accessed via a virtual information store, 98 termed the Management Information Base or MIB. Objects in the 99 MIB are defined using the subset of Abstract Syntax Notation 100 One (ASN.1) [7] defined in the SMI. In particular, each 101 object has a name, a syntax, and an encoding. The name is an 102 object identifier, an administratively assigned name, which 103 specifies an object type. The object type together with an 104 object instance serves to uniquely identify a specific 105 instantiation of the object. For human convenience, we often 106 use a textual string, termed the OBJECT DESCRIPTOR, to also 107 refer to the object type. 109 The syntax of an object type defines the abstract data 110 structure corresponding to that object type. The ASN.1 111 language is used for this purpose. However, the SMI [3] 112 purposely restricts the ASN.1 constructs which may be used. 113 These restrictions are explicitly made for simplicity. 115 The encoding of an object type is simply how that object type 116 is represented using the object type's syntax. Implicitly 117 tied to the notion of an object type's syntax and encoding is 118 how the object type is represented when being transmitted on 119 the network. 121 The SMI specifies the use of the basic encoding rules of ASN.1 122 [8], subject to the additional requirements imposed by the 123 SNMP. 125 4.1. Format of Definitions 127 Section 6 contains contains the specification of all object 128 types contained in this MIB module. The object types are 129 defined using the conventions defined in the SMI, as amended 130 by the extensions specified in [13]. 132 5. Overview 134 Instances of these object types represent attributes of an 135 interface to an ethernet-like communications medium. At 136 present, ethernet-like media are identified by three values of 137 the ifType object in the Internet-standard MIB: 139 ethernet-csmacd(6) 140 iso88023-csmacd(7) 141 starLan(11) 143 For these interfaces, the value of the ifSpecific variable in 144 the MIB-II [6] has the OBJECT IDENTIFIER value: 146 dot3 OBJECT IDENTIFER ::= { experimental 3 } 148 The definitions presented here are based on the IEEE 802.3 149 Layer Management Specification [9], as originally interpreted 150 by Frank Kastenholz of Interlan in [10]. Implementors of 151 these MIB objects should note that the IEEE document 152 explicitly describes (in the form of Pascal pseudocode) when, 153 where, and how various MAC attributes are measured. The IEEE 154 document also describes the effects of MAC actions that may be 155 invoked by manipulating instances of the MIB objects defined 156 here. 158 To the extent that some of the attributes defined in [9] are 159 represented by previously defined objects in the Internet- 160 standard MIB or in the generic interface extensions MIB [11], 161 such attributes are not redundantly represented by objects 162 defined in this memo. Among the attributes represented by 163 objects defined in other memos are the number of octets 164 transmitted or received on a particular interface, the number 165 of frames transmitted or received on a particular interface, 166 the promiscuous status of an interface, the MAC address of an 167 interface, and multicast information associated with an 168 interface. 170 The relationship between an ethernet-like interface and an 171 interface in the context of the Internet-standard MIB is one- 172 to-one. As such, the value of an ifIndex object instance can 173 be directly used to identify corresponding instances of the 174 objects defined herein. 176 6. Definitions 178 RFCxxxx-MIB DEFINITIONS ::= BEGIN 180 IMPORTS 181 experimental, Counter, Gauge 182 FROM RFC1155-SMI 183 OBJECT-TYPE 184 FROM RFC-oooo; 186 -- This MIB module uses the extended OBJECT-TYPE macro as 187 -- defined in [13] 189 -- this is the MIB module for ethernet-like objects 191 dot3 OBJECT IDENTIFIER ::= { experimental 3 } 192 -- the Generic Ethernet-like group 194 -- Implementation of this group is mandatory for all systems 195 -- that attach to an ethernet-like medium. 197 dot3Table OBJECT-TYPE 198 SYNTAX SEQUENCE OF Dot3Entry 199 ACCESS not-accessible 200 STATUS mandatory 201 DESCRIPTION 202 "Status information and control variables for a 203 collection of ethernet-like interfaces attached to 204 a particular system." 205 ::= { dot3 1 } 207 dot3Entry OBJECT-TYPE 208 SYNTAX Dot3Entry 209 ACCESS not-accessible 210 STATUS mandatory 211 DESCRIPTION 212 "Status information and control variables for a 213 particular interface to an ethernet-like medium." 214 INDEX { dot3Index } 215 ::= { dot3Table 1 } 217 Dot3Entry ::= 218 SEQUENCE { 219 dot3Index 220 INTEGER, 221 dot3InitializeMac 222 INTEGER, 223 dot3MacSubLayerStatus 224 INTEGER, 225 dot3MulticastReceiveStatus 226 INTEGER, 227 dot3TxEnabled 228 INTEGER, 229 dot3TestTdrValue 230 Gauge 231 } 233 dot3Index OBJECT-TYPE 234 SYNTAX INTEGER 235 ACCESS read-only 236 STATUS mandatory 237 DESCRIPTION 238 "An index value that uniquely identifies an 239 interface to an ethernet-like medium. The 240 interface identified by a particular value of this 241 index is the same interface as identified by the 242 same value of ifIndex." 243 ::= { dot3Entry 1 } 245 dot3InitializeMac OBJECT-TYPE 246 SYNTAX INTEGER { initialized(1), uninitialized(2) } 247 ACCESS read-write 248 STATUS mandatory 249 DESCRIPTION 250 "The initialization status of the MAC and PLS 251 (Physical Layer Signalling) subsystems for a 252 particular interface. The value initialized(1) 253 signifies that the subsystems for a particular 254 interface have been previously initialized; the 255 value uninitialized(2) signifies that they have 256 not been previously initialized. 258 Each alteration of an instance of this object to 259 either of the values initialized(1) or 260 uninitialized(2) is analogous to an invocation of 261 the initializeMAC action defined in [9] and has 262 the effect of (re-)initializing the MAC and PLS 263 subsystems for the associated interface. In 264 particular, 266 all management counters pertaining to the MAC 267 and PLS subsystems for said interface are 268 reset to zero; 270 the receive and transmit layer management 271 state variables (receiveEnabled and 272 transmitEnabled in [9]) are set to enable 273 reception and transmission of frames; 275 the promiscuous receive function is disabled; 276 and 278 multicast reception is disabled." 279 ::= { dot3Entry 2 } 281 dot3MacSubLayerStatus OBJECT-TYPE 282 SYNTAX INTEGER { enabled(1), disabled(2) } 283 ACCESS read-write 284 STATUS mandatory 285 DESCRIPTION 286 "The operational status of the MAC sublayer for a 287 particular interface. The value enabled(1) 288 signifies that the MAC sublayer for said interface 289 is operational for both transmitting and receiving 290 frames -- that is, that the value of both the 291 receive and transmit layer management state 292 variables (receiveEnabled and transmitEnabled in 293 [9]) for said interface are true. The value 294 disabled(2) signifies that the MAC sublayer for 295 said interface is not operational for either 296 transmitting or receiving frames. In particular, 297 the value of an instance of this object is 298 disabled(2) whenever the value of the 299 corresponding instance of the dot3Enabled object 300 is false(2). 302 Each alteration of an instance of this object to 303 the value enabled(1) is analogous to an invocation 304 of the enableMACSublayer action defined in [9] and 305 has the effect of starting normal transmit and 306 receive operations (from the ``idle'' state) on 307 the associated interface. In particular, such an 308 alteration has the effect of resetting the PLS for 309 said interface and of setting the receive and 310 transmit layer management state variables 311 (receiveEnabled and transmitEnabled in [9]) to be 312 true. 314 Each alteration of an instance of this object to 315 the value disabled(2) is analogous to an 316 invocation of the disableMACSublayer action 317 defined in [9] and has the effect of terminating 318 transmit and receive operations on the associated 319 interface. In particular, such an alteration has 320 the effect of setting the receive and transmit 321 layer management state variables (receiveEnabled 322 and transmitEnabled in [9]) to be false. Any 323 transmissions/receptions in progress are completed 324 before operation is terminated." 325 ::= { dot3Entry 3 } 327 dot3MulticastReceiveStatus OBJECT-TYPE 328 SYNTAX INTEGER { enabled(1), disabled(2) } 329 ACCESS read-write 330 STATUS mandatory 331 DESCRIPTION 332 "The multicast receive status for a particular 333 interface. The value enabled(1) signifies that 334 reception of multicast frames by the MAC sublayer 335 is enabled on said interface. The value 336 disabled(2) signifies that reception of multicast 337 frames by the MAC sublayer is not enabled on said 338 interface. 340 Each alteration of an instance of this object to 341 the value enabled(1) is analogous to an invocation 342 of the enableMulticastReceive action defined in 343 [9] and has the effect of enabling multicast frame 344 reception on the associated interface. Actual 345 reception of multicast frames is only possible on 346 an interface when the values for the associated 347 instances of the dot3MulticastReceiveStatus and 348 dot3MacSubLayerStatus objects are enabled(1) and 349 enabled(1), respectively. 351 Each alteration of an instance of this object to 352 the value disabled(2) is analogous to an 353 invocation of the disableMulticastReceive action 354 defined in [9] and has the effect of inhibiting 355 multicast frame reception on the associated 356 interface." 357 ::= { dot3Entry 4 } 359 dot3TxEnabled OBJECT-TYPE 360 SYNTAX INTEGER { true(1), false(2) } 361 ACCESS read-write 362 STATUS mandatory 363 DESCRIPTION 364 "The transmit layer management state variable 365 (transmitEnabled as defined in [9]) for a 366 particular interface. The value true(1) signifies 367 that the MAC frame transmission is enabled on said 368 interface. The value false(2) signifies that the 369 MAC frame transmission is inhibited on said 370 interface. In particular, the value of an instance 371 of this object is false(2) whenever the value of 372 the corresponding instance of the 373 dot3MacSubLayerStatus object is disabled(2). 375 Each alteration of an instance of this object to 376 the value true(1) is analogous to an invocation of 377 the enableTransmit action defined in [9] and has 378 the effect of enabling MAC sublayer frame 379 transmission on the associated interface. In 380 particular, such an alteration has the effect of 381 setting the transmit layer management state 382 variable (transmitEnabled in [9]) for said 383 interface to be true. 385 Each alteration of an instance of this object to 386 the value false(2) is analogous to an invocation 387 of the disableTransmit action defined in [9] and 388 has the effect of inhibiting MAC sublayer frame 389 transmission on the associated interface. In 390 particular, such an alteration has the effect of 391 setting the transmit layer management state 392 variable (transmitEnabled in [9]) for said 393 interface to be false. Any transmissions in 394 progress are completed before transmission is 395 inhibited." 396 ::= { dot3Entry 5 } 398 dot3TestTdrValue OBJECT-TYPE 399 SYNTAX Gauge 400 ACCESS read-only 401 STATUS mandatory 402 DESCRIPTION 403 "The number of 10 MHz ticks which elapsed between 404 the beginning of a TDR measurement and the 405 collision which ended it, for the most recently 406 executed TDR test. If no TDR test has been 407 executed, or the last TDR value is not available, 408 this object has the value 0." 409 ::= { dot3Entry 6 } 411 -- the Ethernet-like Statistics group 413 -- Implementation of this group is mandatory 415 -- Due to implementation restrictions (e.g. in the instrumentation 416 -- provided by a chipset, or a device driver), some of the counters 417 -- in this group may be difficult or impossible to implement. 418 -- In such cases, an implementator should apply reasonable best 419 -- effort to detect as many occurrences as possible. In any case, 420 -- the value of a counter will be the number actually detected, 421 -- which will always be less or equal to the number of actual 422 -- occurrences. In the extreme case of a total inability to 423 -- detect occurrences, the counter will always be zero. 425 -- Vendors are strongly encouraged to document in user guides and 426 -- other appropriate documentation the conditions under which the 427 -- values of the counters in this group may represent an 428 -- underestimate of the true count. 430 dot3StatsTable OBJECT-TYPE 431 SYNTAX SEQUENCE OF Dot3StatsEntry 432 ACCESS not-accessible 433 STATUS mandatory 434 DESCRIPTION 435 "Statistics for a collection of ethernet-like 436 interfaces attached to a particular system." 437 ::= { dot3 2 } 439 dot3StatsEntry OBJECT-TYPE 440 SYNTAX Dot3StatsEntry 441 ACCESS not-accessible 442 STATUS mandatory 443 DESCRIPTION 444 "Statistics for a particular interface to an 445 ethernet-like medium." 446 INDEX { dot3StatsIndex } 447 ::= { dot3StatsTable 1 } 449 Dot3StatsEntry ::= 450 SEQUENCE { 451 dot3StatsIndex 452 INTEGER, 453 dot3StatsAlignmentErrors 454 Counter, 455 dot3StatsFCSErrors 456 Counter, 457 dot3StatsSingleCollisionFrames 458 Counter, 459 dot3StatsMultipleCollisionFrames 460 Counter, 461 dot3StatsSQETestErrors 462 Counter, 463 dot3StatsDeferredTransmissions 464 Counter, 465 dot3StatsLateCollisions 466 Counter, 467 dot3StatsExcessiveCollisions 468 Counter, 469 dot3StatsInternalMacTransmitErrors 470 Counter, 471 dot3StatsCarrierSenseErrors 472 Counter, 473 dot3StatsExcessiveDeferrals 474 Counter, 475 dot3StatsFrameTooLongs 476 Counter, 477 dot3StatsInRangeLengthErrors 478 Counter, 479 dot3StatsOutOfRangeLengthFields 480 Counter, 481 dot3StatsInternalMacReceiveErrors 482 Counter 483 } 485 dot3StatsIndex OBJECT-TYPE 486 SYNTAX INTEGER 487 ACCESS read-only 488 STATUS mandatory 489 DESCRIPTION 490 "An index value that uniquely identifies an 491 interface to an ethernet-like medium. The 492 interface identified by a particular value of this 493 index is the same interface as identified by the 494 same value of ifIndex." 495 ::= { dot3StatsEntry 1 } 497 dot3StatsAlignmentErrors OBJECT-TYPE 498 SYNTAX Counter 499 ACCESS read-only 500 STATUS mandatory 501 DESCRIPTION 502 "A count of frames received on a particular 503 interface that are not an integral number of 504 octets in length and do not pass the FCS check. 506 The count represented by an instance of this 507 object is incremented when the alignmentError 508 status is returned by the MAC service to the LLC 509 (or other MAC user). Received frames for which 510 multiple error conditions obtain are, according to 511 the conventions of [9], counted exclusively 512 according to the error status presented to the 513 LLC." 514 ::= { dot3StatsEntry 2 } 516 dot3StatsFCSErrors OBJECT-TYPE 517 SYNTAX Counter 518 ACCESS read-only 519 STATUS mandatory 520 DESCRIPTION 521 "A count of frames received on a particular 522 interface that are an integral number of octets in 523 length but do not pass the FCS check. 525 The count represented by an instance of this 526 object is incremented when the frameCheckError 527 status is returned by the MAC service to the LLC 528 (or other MAC user). Received frames for which 529 multiple error conditions obtain are, according to 530 the conventions of [9], counted exclusively 531 according to the error status presented to the 532 LLC." 533 ::= { dot3StatsEntry 3 } 535 dot3StatsSingleCollisionFrames OBJECT-TYPE 536 SYNTAX Counter 537 ACCESS read-only 538 STATUS mandatory 539 DESCRIPTION 540 "A count of successfully transmitted frames on a 541 particular interface for which transmission is 542 inhibited by exactly one collision. 544 A frame that is counted by an instance of this 545 object is also counted by the corresponding 546 instance of either the ifOutUcastPkts or 547 ifOutNUcastPkts object and is not counted by the 548 corresponding instance of the 549 dot3StatsMultipleCollisionFrames object." 550 ::= { dot3StatsEntry 4 } 552 dot3StatsMultipleCollisionFrames OBJECT-TYPE 553 SYNTAX Counter 554 ACCESS read-only 555 STATUS mandatory 556 DESCRIPTION 557 "A count of successfully transmitted frames on a 558 particular interface for which transmission is 559 inhibited by more than one collision. 561 A frame that is counted by an instance of this 562 object is also counted by the corresponding 563 instance of either the ifOutUcastPkts or 564 ifOutNUcastPkts object and is not counted by the 565 corresponding instance of the 566 dot3StatsSingleCollisionFrames object." 567 ::= { dot3StatsEntry 5 } 569 dot3StatsSQETestErrors OBJECT-TYPE 570 SYNTAX Counter 571 ACCESS read-only 572 STATUS mandatory 573 DESCRIPTION 574 "A count of times that the SQE TEST ERROR message 575 is generated by the PLS sublayer for a particular 576 interface. The SQE TEST ERROR message is defined 577 in section 7.2.2.2.4 of [12] and its generation is 578 described in section 7.2.4.6 of the same 579 document." 580 ::= { dot3StatsEntry 6 } 582 dot3StatsDeferredTransmissions OBJECT-TYPE 583 SYNTAX Counter 584 ACCESS read-only 585 STATUS mandatory 586 DESCRIPTION 587 "A count of frames for which the first 588 transmission attempt on a particular interface is 589 delayed because the medium is busy. 591 The count represented by an instance of this 592 object does not include frames involved in 593 collisions." 594 ::= { dot3StatsEntry 7 } 596 dot3StatsLateCollisions OBJECT-TYPE 597 SYNTAX Counter 598 ACCESS read-only 599 STATUS mandatory 600 DESCRIPTION 601 "The number of times that a collision is detected 602 on a particular interface later than 512 bit-times 603 into the transmission of a packet. 605 Five hundred and twelve bit-times corresponds to 606 51.2 microseconds on a 10 Mbit/s system. A (late) 607 collision included in a count represented by an 608 instance of this object is also considered as a 609 (generic) collision for purposes of other 610 collision-related statistics." 611 ::= { dot3StatsEntry 8 } 613 dot3StatsExcessiveCollisions OBJECT-TYPE 614 SYNTAX Counter 615 ACCESS read-only 616 STATUS mandatory 617 DESCRIPTION 618 "A count of frames for which transmission on a 619 particular interface fails due to excessive 620 collisions." 621 ::= { dot3StatsEntry 9 } 623 dot3StatsInternalMacTransmitErrors OBJECT-TYPE 624 SYNTAX Counter 625 ACCESS read-only 626 STATUS mandatory 627 DESCRIPTION 628 "A count of frames for which transmission on a 629 particular interface fails due to an internal MAC 630 sublayer transmit error. A frame is only counted 631 by an instance of this object if it is not counted 632 by the corresponding instance of either the 633 dot3StatsLateCollisions object, the 634 dot3StatsExcessiveCollisions object, the 635 dot3StatsCarrierSenseErrors object, or the 636 dot3StatsExcessiveDeferrals object. 638 The precise meaning of the count represented by an 639 instance of this object is implementation- 640 specific. In particular, an instance of this 641 object may represent a count of transmission 642 errors on a particular interface that are not 643 otherwise counted." 644 ::= { dot3StatsEntry 10 } 646 dot3StatsCarrierSenseErrors OBJECT-TYPE 647 SYNTAX Counter 648 ACCESS read-only 649 STATUS mandatory 650 DESCRIPTION 651 "The number of times that the carrier sense 652 condition was lost or never asserted when 653 attempting to transmit a frame on a particular 654 interface. 656 The count represented by an instance of this 657 object is incremented at most once per 658 transmission attempt, even if the carrier sense 659 condition fluctuates during a transmission 660 attempt." 661 ::= { dot3StatsEntry 11 } 663 dot3StatsExcessiveDeferrals OBJECT-TYPE 664 SYNTAX Counter 665 ACCESS read-only 666 STATUS mandatory 667 DESCRIPTION 668 "A count of frames for which transmission on a 669 particular interface is deferred for an excessive 670 period of time." 671 ::= { dot3StatsEntry 12 } 673 dot3StatsFrameTooLongs OBJECT-TYPE 674 SYNTAX Counter 675 ACCESS read-only 676 STATUS mandatory 677 DESCRIPTION 678 "A count of frames received on a particular 679 interface that exceed the maximum permitted frame 680 size. 682 The count represented by an instance of this 683 object is incremented when the frameTooLong status 684 is returned by the MAC service to the LLC (or 685 other MAC user). Received frames for which 686 multiple error conditions obtain are, according to 687 the conventions of [9], counted exclusively 688 according to the error status presented to the 689 LLC." 690 ::= { dot3StatsEntry 13 } 692 dot3StatsInRangeLengthErrors OBJECT-TYPE 693 SYNTAX Counter 694 ACCESS read-only 695 STATUS mandatory 696 DESCRIPTION 697 "A count of frames received on a particular 698 interface with a length field value that falls 699 between the minimum unpadded LLC data size and the 700 maximum allowed LLC data size inclusive and that 701 does not match the number of LLC data octets 702 received. 704 The count represented by an instance of this 705 object also includes frames for which the length 706 field value is less than the minimum unpadded LLC 707 data size." 708 ::= { dot3StatsEntry 14 } 710 dot3StatsOutOfRangeLengthFields OBJECT-TYPE 711 SYNTAX Counter 712 ACCESS read-only 713 STATUS mandatory 714 DESCRIPTION 715 "A count of frames received on a particular 716 interface for which the length field value exceeds 717 the maximum allowed LLC data size. 719 The count represented by an instance of this 720 object is not incremented in implementations that 721 observe Ethernet encapsulation conventions (by 722 which the IEEE 802.3 length field is interpreted 723 as the Ethernet Type field)." 724 ::= { dot3StatsEntry 15 } 726 dot3StatsInternalMacReceiveErrors OBJECT-TYPE 727 SYNTAX Counter 728 ACCESS read-only 729 STATUS mandatory 730 DESCRIPTION 731 "A count of frames for which reception on a 732 particular interface fails due to an internal MAC 733 sublayer receive error. A frame is only counted by 734 an instance of this object if it is not counted by 735 the corresponding instance of either the 736 dot3StatsFrameTooLongs object, the 737 dot3StatsAlignmentErrors object, the 738 dot3StatsFCSErrors object, the 739 dot3StatsInRangeLengthErrors object, or the 740 dot3StatsOutOfRangeLengthFields object. 742 The precise meaning of the count represented by an 743 instance of this object is implementation- 744 specific. In particular, an instance of this 745 object may represent a count of receive errors on 746 a particular interface that are not otherwise 747 counted." 748 ::= { dot3StatsEntry 16 } 750 -- the Ethernet-like Collision Statistics group 752 -- Implementation of this group is optional; it is appropriate 753 -- for all systems which have the necessary metering 755 dot3CollTable OBJECT-TYPE 756 SYNTAX SEQUENCE OF Dot3CollEntry 757 ACCESS not-accessible 758 STATUS mandatory 759 DESCRIPTION 760 "A collection of collision histograms for a 761 particular set of interfaces." 762 ::= { dot3 5 } 764 dot3CollEntry OBJECT-TYPE 765 SYNTAX Dot3CollEntry 766 ACCESS not-accessible 767 STATUS mandatory 768 DESCRIPTION 769 "A cell in the histogram of per-frame collisions 770 for a particular interface. An instance of this 771 object represents the frequency of individual MAC 772 frames for which the transmission (successful or 773 otherwise) on a particular interface is 774 accompanied by a particular number of media 775 collisions." 776 INDEX { dot3CollIndex, dot3CollCount } 777 ::= { dot3CollTable 1 } 779 Dot3CollEntry ::= 780 SEQUENCE { 781 dot3CollIndex 782 INTEGER, 783 dot3CollCount 784 INTEGER, 785 dot3CollFrequency 786 Counter 787 } 789 dot3CollIndex OBJECT-TYPE 790 SYNTAX INTEGER 791 ACCESS read-only 792 STATUS mandatory 793 DESCRIPTION 794 "The index value that uniquely identifies the 795 interface to which a particular collision 796 histogram cell pertains. The interface identified 797 by a particular value of this index is the same 798 interface as identified by the same value of 799 ifIndex." 800 ::= { dot3CollEntry 1 } 802 dot3CollCount OBJECT-TYPE 803 SYNTAX INTEGER (1..16) 804 ACCESS read-only 805 STATUS mandatory 806 DESCRIPTION 807 "The number of per-frame media collisions for 808 which a particular collision histogram cell 809 represents the frequency on a particular 810 interface." 811 ::= { dot3CollEntry 2 } 813 dot3CollFrequency OBJECT-TYPE 814 SYNTAX Counter 815 ACCESS read-only 816 STATUS mandatory 817 DESCRIPTION 818 "A count of individual MAC frames for which the 819 transmission (successful or otherwise) on a 820 particular interface is accompanied by a 821 particular number of media collisions." 822 ::= { dot3CollEntry 3 } 824 -- 802.3 Tests 826 -- The ifExtnsTestTable defined in [11] provides a common means 827 -- for a manager to test any interface corresponding to a value 828 -- of ifIndex. 830 -- At this time, one well known test (testFullDuplexLoopBack) is 831 -- defined in [11]. For ethernet-like interfaces, this test 832 -- configures the MAC chip and executes an internal loopback 833 -- test of memory and the MAC chip logic. This loopback test can 834 -- only be executed if the interface is offline. Once the test 835 -- has completed, the MAC chip should be reinitialized for network 836 -- operation, but it should remain offline. 838 -- If an error occurs during a test, the object ifExtnsTestResult 839 -- (defined in [11]) will be set to failed(7). The following two 840 -- OBJECT IDENTIFIERs may be used to provided more information as 841 -- values for the object ifExtnsTestCode in [11]: 843 dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } 845 -- couldn't initialize MAC chip for test 846 dot3ErrorInitError OBJECT IDENTIFIER ::= { dot3Errors 1 } 848 -- expected data not received (or not 849 -- received correctly) in loopback test 850 dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 } 852 -- TDR Test 854 -- Another test, specific to ethernet-like interfaces, is Time-domain 855 -- Reflectometry (TDR) which is defined as follows: 857 dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } 858 dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 } 860 -- A TDR test returns as its result the time interval between the 861 -- most recent TDR test transmission and the subsequent detection 862 -- of a collision. This interval is based on a 10 MHz clock and 863 -- should be normalized if the time base is other than 10 MHz. 864 -- On successful completion of a TDR test, the result is stored 865 -- as the value of the appropriate instance of the MIB object 866 -- dot3TestTdrValue, and the OBJECT IDENTIFIER of that instance 867 -- is stored in the corresponding instance of ifExtnsTestResult 868 -- (thereby indicating where the result has been stored). 870 -- 802.3 Hardware Chipsets 872 -- The object ifExtnsChipSet is provided in [11] to identify the 873 -- MAC hardware used to communcate on an interface. The following 874 -- hardware chipsets are provided for 802.3: 876 dot3ChipSets OBJECT IDENTIFIER ::= { dot3 8 } 877 dot3ChipSetAMD OBJECT IDENTIFIER ::= { dot3ChipSets 1 } 878 dot3ChipSetAMD7990 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 1 } 879 dot3ChipSetAMD79900 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 2 } 881 dot3ChipSetIntel OBJECT IDENTIFIER ::= { dot3ChipSets 2 } 882 dot3ChipSetIntel82586 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 1 } 883 dot3ChipSetIntel82596 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 2 } 885 dot3ChipSetSeeq OBJECT IDENTIFIER ::= { dot3ChipSets 3 } 886 dot3ChipSetSeeq8003 OBJECT IDENTIFIER ::= { dot3ChipSetSeeq 1 } 888 dot3ChipSetNational OBJECT IDENTIFIER ::= { dot3ChipSets 4 } 889 dot3ChipSetNational8390 OBJECT IDENTIFIER ::= 890 { dot3ChipSetNational 1 } 891 dot3ChipSetNationalSonic OBJECT IDENTIFIER ::= 892 { dot3ChipSetNational 2 } 894 dot3ChipSetFujitsu OBJECT IDENTIFIER ::= { dot3ChipSets 5 } 895 dot3ChipSetFujitsu86950 OBJECT IDENTIFIER ::= 896 { dot3ChipSetFujitsu 1 } 898 -- For those chipsets not represented above, OBJECT IDENTIFIER 899 -- assignment is required in other documentation, e.g., assignment 900 -- within that part of the registration tree delegated to 901 -- individual enterprises (see [3]). 903 END 904 7. Acknowledgements 906 This document was produced by the Transmission MIB Working 907 Group. 909 This document is based on a document written by Frank 910 Kastenholz of Interlan entitled IEEE 802.3 Layer Management 911 Draft M compatible MIB for TCP/IP Networks [10]. This 912 document has been modestly reworked, initially by the SNMP 913 Working Group, and then by the Transmission Working Group, to 914 reflect the current conventions for defining objects for MIB 915 interfaces. James Davin, of the MIT Laboratory for Computer 916 Science, and Keith McCloghrie of Hughes LAN Systems, 917 contributed to later drafts of this memo. Marshall Rose of 918 Performance Systems International, Inc. converted the document 919 into its current concise format. Thanks to Frank Kastenholz 920 of Interlan and Louis Steinberg of IBM for their 921 experimentation. 923 8. References 925 [1] V. Cerf, IAB Recommendations for the Development of 926 Internet Network Management Standards. Internet Working 927 Group Request for Comments 1052. Network Information 928 Center, SRI International, Menlo Park, California, 929 (April, 1988). 931 [2] V. Cerf, Report of the Second Ad Hoc Network Management 932 Review Group, Internet Working Group Request for Comments 933 1109. Network Information Center, SRI International, 934 Menlo Park, California, (August, 1989). 936 [3] M.T. Rose and K. McCloghrie, Structure and Identification 937 of Management Information for TCP/IP-based internets, 938 Internet Working Group Request for Comments 1155. 939 Network Information Center, SRI International, Menlo 940 Park, California, (May, 1990). 942 [4] K. McCloghrie and M.T. Rose, Management Information Base 943 for Network Management of TCP/IP-based internets, 944 Internet Working Group Request for Comments 1156. 945 Network Information Center, SRI International, Menlo 946 Park, California, (May, 1990). 948 [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, 949 Simple Network Management Protocol, Internet Working 950 Group Request for Comments 1157. Network Information 951 Center, SRI International, Menlo Park, California, (May, 952 1990). 954 [6] K. McCloghrie and M.T. Rose (editors), Management 955 Information Base for Network Management of TCP/IP-based 956 internets: MIB-II, Internet Working Group Request for 957 Comments 1213. Network Information Center, SRI 958 International, Menlo Park, California, (March, 1991). 960 [7] Information processing systems - Open Systems 961 Interconnection - Specification of Abstract Syntax 962 Notation One (ASN.1), International Organization for 963 Standardization. International Standard 8824, (December, 964 1987). 966 [8] Information processing systems - Open Systems 967 Interconnection - Specification of Basic Encoding Rules 968 for Abstract Notation One (ASN.1), International 969 Organization for Standardization. International Standard 970 8825, (December, 1987). 972 [9] IEEE, IEEE 802.3 Layer Management, (November, 1988). 974 [10] F. Kastenholz, IEEE 802.3 Layer Management Draft M 975 compatible MIB for TCP/IP Networks, electronic mail 976 message to mib-wg@nnsc.nsf.net, (June 9, 1989). 978 [11] K. McCloghrie, Extensions to the Generic-Interface MIB, 979 RFC draft, SNMP Working Group (in preparation). 981 [12] IEEE. Carrier Sense Multiple Access with Collision 982 Detection (CSMA/CD) Access Method and Physical Layer 983 Specifications. ANSI/IEEE Std 802.3-1985. 985 [13] M.T. Rose, K. McCloghrie (editors), Concise MIB 986 Definitions, Internet Working Group Request for Comments 987 1212, Network Information Center, SRI International, 988 Menlo Park, California, (March, 1991). 990 Table of Contents 992 1 Status of this Memo ................................... 1 993 2 Abstract .............................................. 1 994 3 Historical Perspective ................................ 2 995 4 Objects ............................................... 4 996 4.1 Format of Definitions ............................... 4 997 5 Overview .............................................. 5 998 6 Definitions ........................................... 6 999 6.1 The Generic Ethernet-like Group ..................... 7 1000 6.2 The Ethernet-Like Statistics Group .................. 12 1001 6.3 The Ethernet-like Collision Statistics Group ........ 20 1002 6.4 802.3 Tests ......................................... 22 1003 6.5 802.3 Hardware Chipsets ............................. 24 1004 7 Acknowledgements ...................................... 25 1005 8 References ............................................ 26