idnits 2.17.1 draft-ietf-hubmib-etherif-mib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 481 has weird spacing: '...issions dot...' == Line 487 has weird spacing: '...cvError dot3S...' -- 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 1997) is 9652 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) -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Downref: Normative reference to an Informational RFC: RFC 1369 (ref. '15') Summary: 17 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Hub MIB Working Group J. Flick 3 INTERNET DRAFT Hewlett-Packard Company 4 J. Johnson 5 RedBack Networks 6 F. Kastenholz 7 FTP Software, Inc. 8 November 1997 10 Definitions of Managed Objects for 11 the Ethernet-like Interface Types 13 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Copyright Notice 35 Copyright (C) The Internet Society (1997). All Rights Reserved. 37 Abstract 39 This memo is an extension to the SNMP MIB. It specifies an IAB 40 standards track protocol for the Internet community, and requests 41 discussion and suggestions for improvements. The origin of this memo 42 is from RFC 1650 ''Definitions of Managed Objects for the Ethernet- 43 like Interface Types using SMIv2.'' This memo extends that 44 specification by including management information useful for the 45 management of 100BaseT ethernet interfaces. 47 Distribution of this memo is unlimited. Please forward comments to 48 hubmib@hprnd.rose.hp.com. 50 1. Introduction 52 This memo defines a portion of the Management Information Base (MIB) 53 for use with network management protocols in the Internet community. 54 In particular, it defines objects for managing ethernet-like 55 interfaces. 57 This memo also includes a MIB module. This MIB module extends the 58 list of managed objects specified in the earlier version of this MIB: 59 RFC1650 [11]. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [13]. 65 2. The SNMP Network Management Framework 67 The SNMP Network Management Framework consists of several components. 68 For the purpose of this specification, the applicable components of 69 the Framework are the SMI and related documents [2, 3, 4], which 70 define the mechanisms used for describing and naming objects for the 71 purpose of management. 73 The Framework permits new objects to be defined for the purpose of 74 experimentation and evaluation. 76 2.1. Object Definitions 78 Managed objects are accessed via a virtual information store, termed 79 the Management Information Base or MIB. Objects in the MIB are 80 defined using the subset of Abstract Syntax Notation One (ASN.1) [1] 81 defined in the SMI [2]. In particular, each object object type is 82 named by an OBJECT IDENTIFIER, an administratively assigned name. 83 The object type together with an object instance serves to uniquely 84 identify a specific instantiation of the object. For human 85 convenience, we often use a textual string, termed the descriptor, to 86 refer to the object type. 88 3. Change Log 90 This section enumerates changes made to RFC 1650 to produce this 91 document. 93 (1) The MODULE-IDENTITY has been updated to reflect the changes 94 in the MIB. 96 (2) A new object, dot3StatsSymbolErrors, has been added. 98 (3) The definition of the object dot3StatsIndex has been 99 converted to use the SMIv2 OBJECT-TYPE macro. 101 (4) A new conformance group, etherStats100MbsGroup, has been 102 added. 104 (5) A new compliance statement, ether100MbsCompliance, has 105 been added. 107 (6) The Acknowledgements were extended to provide a more 108 complete history of the origin of this document. 110 (7) The discussion of ifType has been expanded. 112 (8) A section on mapping of Interfaces MIB objects has 113 been added. 115 (9) A section defining the relationship of this MIB to 116 the MAU MIB has been added. 118 (10) A section on the mapping of IEEE 802.3 managed objects 119 to this MIB and the Interfaces MIB has been added. 121 (11) Comverted the dot3Tests, dot3Errors, and dot3ChipSets 122 OIDs to use the OBJECT-IDENTITY macro. 124 (12) An intellectual property notice and copyright notice 125 were added, as required by RFC 2026. 127 4. Overview 129 Instances of these object types represent attributes of an interface 130 to an ethernet-like communications medium. At present, ethernet-like 131 media are identified by the following values of the ifType object in 132 the Interfaces MIB [12]: 134 ethernetCsmacd(6) 135 iso88023Csmacd(7) 136 starLan(11) 138 The definitions presented here are based on the IEEE 802.3 Layer 139 Management Specification [5], as originally interpreted by Frank 140 Kastenholz then of Interlan in [7]. Implementors of these MIB 141 objects should note that the IEEE document explicitly describes (in 142 the form of Pascal pseudocode) when, where, and how various MAC 143 attributes are measured. The IEEE document also describes the 144 effects of MAC actions that may be invoked by manipulating instances 145 of the MIB objects defined here. 147 To the extent that some of the attributes defined in [5] are 148 represented by previously defined objects in the Internet-standard 149 MIB or in the Interfaces Group Evolution MIB [12], such attributes 150 are not redundantly represented by objects defined in this memo. 151 Among the attributes represented by objects defined in other memos 152 are the number of octets transmitted or received on a particular 153 interface, the number of frames transmitted or received on a 154 particular interface, the promiscuous status of an interface, the MAC 155 address of an interface, and multicast information associated with an 156 interface. 158 4.1. Relation to MIB-2 160 This section applies only when this MIB is used in conjunction with 161 the "old" (RFC 1213) interface group. 163 The relationship between an ethernet-like interface and an interface 164 in the context of the Internet-standard MIB is one-to-one. As such, 165 the value of an ifIndex object instance can be directly used to 166 identify corresponding instances of the objects defined herein. 168 For agents which implement the (now deprecated) ifSpecific object, an 169 instance of that object that is associated with an ethernet-like 170 interface has the OBJECT IDENTIFIER value: 172 dot3 OBJECT IDENTIFER ::= { transmission 7 } 174 4.2. Relation to the Interfaces MIB 176 The Interface MIB [12] requires that any MIB which is an adjunct of 177 the Interface MIB clarify specific areas within the Interface MIB. 178 These areas were intentionally left vague in the Interface MIB to 179 avoid over constraining the MIB, thereby precluding management of 180 certain media-types. 182 Section 3.3 of [12] enumerates several areas which a media-specific 183 MIB must clarify. Each of these areas is addressed in a following 184 subsection. The implementor is referred to [12] in order to 185 understand the general intent of these areas. 187 4.2.1. Layering Model 189 This MIB does not provide for layering. There are no sublayers. 191 EDITOR'S NOTE: 193 One could foresee the development of an 802.2 and enet-transceiver 194 MIB. They could be higher and lower sublayers, respectively. All 195 that THIS document should do is allude to the possibilities and urge 196 the implementor to be aware of the possibility and that they may have 197 requirements which supersede the requirements in this document. 199 4.2.2. Virtual Circuits 201 This medium does not support virtual circuits and this area is not 202 applicable to this MIB. 204 4.2.3. ifTestTable 206 This MIB defines two tests for media which are instrumented with this 207 MIB; TDR and Loopback. Implementation of these tests is not 208 required. Many common interface chips do not support one or both of 209 these tests. 211 These two tests are provided as a convenience, allowing a common 212 method to invoke the test. 214 Standard MIBs do not include objects in which to return the results 215 of the TDR test. Any needed objects MUST be provided in the vendor 216 specific MIB. 218 Note that the ifTestTable is now deprecated. Work is underway to 219 define a replacement MIB for system and interface testing. It is 220 expected that the tests defined in this document will be usable in 221 this replacement MIB. 223 4.2.4. ifRcvAddressTable 225 This table contains all IEEE 802.3 addresses, unicast, multicast, and 226 broadcast, for which this interface will receive packets and forward 227 them up to a higher layer entity for local consumption. The format 228 of the address, contained in ifRcvAddressAddress, is the same as for 229 ifPhysAddress. 231 In the event that the interface is part of a MAC bridge, this table 232 does not include unicast addresses which are accepted for possible 233 forwarding out some other port. This table is explicitly not 234 intended to provide a bridge address filtering mechanism. 236 4.2.5. ifPhysAddress 238 This object contains the IEEE 802.3 address which is placed in the 239 source-address field of any Ethernet, Starlan, or IEEE 802.3 frames 240 that originate at this interface. Usually this will be kept in ROM 241 on the interface hardware. Some systems may set this address via 242 software. 244 In a system where there are several such addresses the designer has a 245 tougher choice. The address chosen should be the one most likely to 246 be of use to network management (e.g. the address placed in ARP 247 responses for systems which are primarily IP systems). 249 If the designer truly can not chose, use of the factory- provided ROM 250 address is suggested. 252 If the address can not be determined, an octet string of zero length 253 should be returned. 255 The address is stored in binary in this object. The address is 256 stored in "canonical" bit order, that is, the Group Bit is positioned 257 as the low-order bit of the first octet. Thus, the first byte of a 258 multicast address would have the bit 0x01 set. 260 4.2.6. ifType 262 This MIB applies to interfaces which have any of the following ifType 263 values: 265 ethernetCsmacd(6) 266 iso88023Csmacd(7) 267 starLan(11) 269 It is RECOMMENDED that all Ethernet-like interfaces use an ifType of 270 ethernetCsmacd(6) regardless of the speed that the interface is 271 running or the link-layer encapsulation in use. iso88023Csmacd(7) 272 and starLan(11) are supported for backwards compatability. 274 There are two other interface types defined in the IANAifType-MIB for 275 100 Mbit Ethernet. They are fastEther(62), and fastEtherFX(69). 276 This document takes the position that an Ethernet is an Ethernet, and 277 Ethernet interfaces SHOULD always have the same value of ifType. 279 Information on the particular flavor of Ethernet that an interface is 280 running is available from ifSpeed in the Interfaces MIB, and 281 ifMauType in the 802.3 MAU MIB. An Ethernet-like interface SHOULD 282 NOT use the fastEther(62) or fastEtherFX(69) ifTypes. 284 Interfaces with any of the supported ifType values map to the 285 EtherLike-MIB in the same manner. Which compliance statement an 286 interface should implement is dependent on the maximum speed 287 supported on the interface. The EtherLike-MIB etherCompliance 288 compliance statement applies to all Ethernet-like interfaces whose 289 maximum supported speed is 10 Mbit/sec or less. There are no 290 implementation differences. Similarly, the EtherLike-MIB 291 ether100MbsCompliance compliance statement applies to all Ethernet- 292 like interfaces whose maximum supported speed of 100Mbit/sec. 294 An interface that is capable of operating at 100Mbit/sec MUST 295 implement the ether100MbsCompliance compliance statement, even if it 296 is currently operating at a lower speed. Counters in the 297 ether100MbsCompliance compliance statement that only apply to 100 298 Mbit interfaces would simply not increment when the interface is 299 operating at a lower speed. 301 4.2.7. Specific Interface MIB Objects 303 The following table provides specific implementation guidelines for 304 applying the interface group objects to ethernet-like media. 306 Object 308 ifIndex Each ethernet-like interface is 309 represented by an ifEntry. The 310 dot3StatsTable in this MIB module is 311 indexed by dot3StatsIndex. The interface 312 identified by a particular value of 313 dot3StatsIndex is the same interface as 314 identified by the same value of ifIndex. 316 ifDescr Refer to [12]. 318 ifType Refer to section 4.2.6. 320 ifMtu 1500 octets. 322 ifSpeed The current operational speed of the 323 interface in bits per second. For 324 current ethernet-like interfaces, this 325 will be equal to 1,000,000 (1 million), 326 10,000,000 (10 million), or 100,000,000 327 (100 million). If the interface 328 implements auto-negotiation, 329 auto-negotiation is enabled for this 330 interface, and the interface has not yet 331 negotiated to an operational speed, this 332 object SHOULD reflect the maximum speed 333 supported by the interface. Note that 334 this object MUST NOT indicate a doubled 335 value when operating in full-duplex 336 mode. It MUST indicate the correct 337 line speed regardless of the current 338 duplex mode. The correct object to use 339 to determine the duplex mode of the 340 interface is the ifMauType object in the 341 802.3 MAU MIB. 343 ifPhysAddress Refer to section 4.2.5. 345 ifAdminStatus Write access is not required. Support 346 for 'testing' is not required. 348 ifOperStatus The operational state of the interface. 349 Support for 'testing' is not required. 350 The value 'dormant' has no meaning for 351 an ethernet-like interface. 353 ifLastChange Refer to [12]. 355 ifInOctets The number of octets in valid MAC frames 356 received on this interface, including 357 the MAC header and FCS. 359 ifInUcastPkts Refer to [12]. 361 ifInDiscards Refer to [12]. 363 ifInErrors The sum for this interface of 364 dot3StatsAlignmentErrors, 365 dot3StatsFCSErrors, 366 dot3StatsFrameTooLongs, 367 dot3StatsInternalMacReceiveErrors and 368 dot3StatsSymbolErrors. 370 ifInUnknownProtos Refer to [12]. 372 ifOutOctets The number of octets transmitted in 373 valid MAC frames on this interface, 374 including the MAC header and FCS. 376 ifOutUcastPkts Refer to [12]. 378 ifOutDiscards Refer to [12]. 380 ifOutErrors The sum for this interface of: 381 dot3StatsSQETestErrors, 382 dot3StatsLateCollisions, 383 dot3StatsExcessiveCollisions, 384 dot3StatsInternalMacTransmitErrors and 385 dot3StatsCarrierSenseErrors. 387 ifName Locally-significant textual name for the 388 interface (e.g. lan0). 390 ifInMulticastPkts Refer to [12]. 392 ifInBroadcastPkts Refer to [12]. 394 ifOutMulticastPkts Refer to [12]. 396 ifOutBroadcastPkts Refer to [12]. 398 ifHCInOctets 64-bit versions of counters. Required 399 ifHCOutOctets for ethernet-like interfaces that are 400 capable of operating at 20Mbit/sec or 401 faster, even if the interface is 402 currently operating at less than 403 20Mbit/sec. 405 ifHCInUcastPkts 64-bit versions of packet counters. 406 ifHCInMulticastPkts Support for these counters is not 407 ifHCInBroadcastPkts required for the interface types 408 ifHCOutUcastPkts supported by this MIB. They are only 409 ifHCOutMulticastPkts required for interfaces capable of 410 ifHCOutBroadcastPkts operating at 640Mbit/sec or faster. 411 Note that a future revision of this 412 document may support faster interfaces, 413 and therefore may require support for 414 these counters. 416 ifLinkUpDownTrapEnable Refer to [12]. Default is 'enabled' 418 ifHighSpeed The current operational speed of the 419 interface in millions of bits per 420 second. For current ethernet-like 421 interfaces, this will be equal to 1, 10, 422 or 100. If the interface implements 423 auto-negotiation, auto-negotiation is 424 enabled for this interface, and the 425 interface has not yet negotiated to an 426 operational speed, this object SHOULD 427 reflect the maximum speed supported by 428 the interface. Note that this object 429 MUST NOT indicate a doubled value when 430 operating in full-duplex mode. It MUST 431 indicate the correct line speed 432 regardless of the current duplex mode. 433 The correct object to use to determine 434 the duplex mode of the interface is the 435 ifMauType object in the 802.3 MAU MIB. 437 ifPromiscuousMode Refer to [12]. 439 ifConnectorPresent This will normally be 'true'. 441 ifAlias Refer to [12]. 443 ifCounterDiscontinuityTime Refer to [12]. 445 ifStackHigherLayer Refer to section 4.2.1. 446 ifStackLowerLayer 447 ifStackStatus 449 ifRcvAddressAddress Refer to section 4.2.4. 450 ifRcvAddressStatus 451 ifRcvAddressType 453 4.3. Relation to the 802.3 MAU MIB 455 Support for the mauModIfCompl compliance statement of the MAU-MIB 456 [14] is REQUIRED for Ethernet-like interfaces. This MIB is needed in 457 order to allow applications to determine the current MAU type in use 458 by the interface. The MAU type indicates not only the media type in 459 use, but also indicates whether the interface is operating in half- 460 duplex or full-duplex mode. Implementing this MIB module without 461 implementing the MAU-MIB would leave applications with no standard 462 way to determine the duplex mode of the interface. 464 4.4. Mapping of IEEE 802.3 Managed Objects 466 IEEE 802.3 Managed Object Corresponding SNMP Object 467 oMacEntity 468 .aMACID dot3StatsIndex or 469 IF-MIB - ifIndex 470 .aFramesTransmittedOK IF-MIB - ifOutUCastPkts + 471 ifOutMulticastPkts + 472 ifOutBroadcastPkts 473 .aSingleCollisionFrames dot3StatsSingleCollisionFrames 474 .aMultipleCollisionFrames dot3StatsMultipleCollisionFrames 475 .aFramesReceivedOK IF-MIB - ifInUcastPkts + 476 ifInMulticastPkts + 477 ifInBroadcastPkts 478 .aFrameCheckSequenceErrors dot3StatsFCSErrors 479 .aAlignmentErrors dot3StatsAlignmentErrors 480 .aOctetsTransmittedOK IF-MIB - ifOutOctets 481 .aFramesWithDeferredXmissions dot3StatsDeferredTransmissions 482 .aLateCollisions dot3StatsLateCollisions 483 .aFramesAbortedDueToXSColls dot3StatsExcessiveCollisions 484 .aFramesLostDueToIntMACXmitError dot3StatsInternalMacTransmitErrors 485 .aCarrierSenseErrors dot3StatsCarrierSenseErrors 486 .aOctetsReceivedOK IF-MIB - ifInOctets 487 .aFramesLostDueToIntMACRcvError dot3StatsInternalMacReceiveErrors 488 .aPromiscuousStatus IF-MIB - ifPromiscuousMode 489 .aReadMulticastAddressList IF-MIB - ifRcvAddressTable 490 .aMulticastFramesXmittedOK IF-MIB - ifOutMulticastPkts 491 .aBroadcastFramesXmittedOK IF-MIB - ifOutBroadcastPkts 492 .aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts 493 .aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts 494 .aFrameTooLongErrors dot3StatsFrameTooLongs 495 .aReadWriteMACAddress IF-MIB - ifPhysAddress 496 .aCollisionFrames dot3CollFrequencies 497 .acAddGroupAddress IF-MIB - ifRcvAddressTable 498 .acDeleteGroupAddress IF-MIB - ifRcvAddressTable 499 .acExecuteSelfTest dot3TestLoopBack 501 oPHYEntity 502 .aSQETestErrors dot3StatsSQETestErrors 503 .aSymbolErrorDuringCarrier dot3StatsSymbolErrors 505 The following IEEE 802.3 managed objects have been removed from this 506 MIB module as a result of implementation feedback: 508 oMacEntity 509 .aFramesWithExcessiveDeferral 510 .aInRangeLengthErrors 511 .aOutOfRangeLengthField 512 .aMACEnableStatus 513 .aTransmitEnableStatus 514 .aMulticastReceiveStatus 515 .acInitializeMAC 517 Please see [15] for the detailed reasoning on why these objects were 518 removed. 520 5. Definitions 522 EtherLike-MIB DEFINITIONS ::= BEGIN 524 IMPORTS 525 MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, 526 Counter32, mib-2, transmission 527 FROM SNMPv2-SMI 528 MODULE-COMPLIANCE, OBJECT-GROUP 529 FROM SNMPv2-CONF 530 ifIndex, InterfaceIndex 531 FROM IF-MIB; 533 etherMIB MODULE-IDENTITY 534 LAST-UPDATED "9711102157Z" -- November 10, 1997 535 ORGANIZATION "IETF 802.3 Hub MIB Working Group" 536 CONTACT-INFO 537 "WG E-mail: hubmib@hprnd.rose.hp.com 539 Chair: Dan Romascanu 540 Postal: Madge Networks 541 Atidum Technology Park, Bldg. 3 542 Tel Aviv 61131 543 Israel 544 Tel: +972 3 645 8414 545 E-mail: dromasca@madge.com 547 Editor: John Flick 548 Postal: Hewlett-Packard Company 549 8000 Foothills Blvd. M/S 5556 550 Roseville, CA 95747-5556 551 USA 552 Tel: +1 916 785 4018 553 Fax: +1 916 785 3583 554 E-mail: johnf@hprnd.rose.hp.com 556 Editor: Jeffrey Johnson 557 Postal: RedBack Networks 558 2570 North First Street, Suite 410 559 San Jose, CA, 95131 560 USA 561 Tel: +1 408 571 2699 562 Fax: +1 408 571 2698 563 E-Mail: jeff@redbacknetworks.com" 565 DESCRIPTION "The MIB module to describe generic objects for 566 Ethernet-like network interfaces. This MIB is an 567 updated version of the Ethernet-like MIB in RFC 568 1650." 570 REVISION "9711102157Z" 571 DESCRIPTION "Updated to include support for 100 Mb/sec 572 interfaces." 574 REVISION "9402030400Z" 575 DESCRIPTION "Version published as RFC 1650." 576 ::= { mib-2 35 } 578 etherMIBObjects OBJECT IDENTIFIER ::= { etherMIB 1 } 580 dot3 OBJECT IDENTIFIER ::= { transmission 7 } 582 -- the Ethernet-like Statistics group 584 dot3StatsTable OBJECT-TYPE 585 SYNTAX SEQUENCE OF Dot3StatsEntry 586 MAX-ACCESS not-accessible 587 STATUS current 588 DESCRIPTION "Statistics for a collection of ethernet-like 589 interfaces attached to a particular system." 590 ::= { dot3 2 } 592 dot3StatsEntry OBJECT-TYPE 593 SYNTAX Dot3StatsEntry 594 MAX-ACCESS not-accessible 595 STATUS current 596 DESCRIPTION "Statistics for a particular interface to an 597 ethernet-like medium." 598 INDEX { dot3StatsIndex } 599 ::= { dot3StatsTable 1 } 601 Dot3StatsEntry ::= 602 SEQUENCE { 603 dot3StatsIndex InterfaceIndex, 604 dot3StatsAlignmentErrors Counter32, 605 dot3StatsFCSErrors Counter32, 606 dot3StatsSingleCollisionFrames Counter32, 607 dot3StatsMultipleCollisionFrames Counter32, 608 dot3StatsSQETestErrors Counter32, 609 dot3StatsDeferredTransmissions Counter32, 610 dot3StatsLateCollisions Counter32, 611 dot3StatsExcessiveCollisions Counter32, 612 dot3StatsInternalMacTransmitErrors Counter32, 613 dot3StatsCarrierSenseErrors Counter32, 614 dot3StatsFrameTooLongs Counter32, 615 dot3StatsInternalMacReceiveErrors Counter32, 616 dot3StatsEtherChipSet OBJECT IDENTIFIER, 617 dot3StatsSymbolErrors Counter32 618 } 620 dot3StatsIndex OBJECT-TYPE 621 SYNTAX InterfaceIndex 622 MAX-ACCESS read-only 623 STATUS current 624 DESCRIPTION "An index value that uniquely identifies an 625 interface to an ethernet-like medium. The 626 interface identified by a particular value of 627 this index is the same interface as identified 628 by the same value of ifIndex." 629 ::= { dot3StatsEntry 1 } 631 dot3StatsAlignmentErrors OBJECT-TYPE 632 SYNTAX Counter32 633 MAX-ACCESS read-only 634 STATUS current 635 DESCRIPTION "A count of frames received on a particular 636 interface that are not an integral number of 637 octets in length and do not pass the FCS check. 639 The count represented by an instance of this 640 object is incremented when the alignmentError 641 status is returned by the MAC service to the 642 LLC (or other MAC user). Received frames for 643 which multiple error conditions obtain are, 644 according to the conventions of IEEE 802.3 645 Layer Management, counted exclusively according 646 to the error status presented to the LLC." 647 REFERENCE "IEEE 802.3 Layer Management" 648 ::= { dot3StatsEntry 2 } 650 dot3StatsFCSErrors OBJECT-TYPE 651 SYNTAX Counter32 652 MAX-ACCESS read-only 653 STATUS current 654 DESCRIPTION "A count of frames received on a particular 655 interface that are an integral number of octets 656 in length but do not pass the FCS check. 658 The count represented by an instance of this 659 object is incremented when the frameCheckError 660 status is returned by the MAC service to the 661 LLC (or other MAC user). Received frames for 662 which multiple error conditions obtain are, 663 according to the conventions of IEEE 802.3 664 Layer Management, counted exclusively according 665 to the error status presented to the LLC." 666 REFERENCE "IEEE 802.3 Layer Management" 667 ::= { dot3StatsEntry 3 } 669 dot3StatsSingleCollisionFrames OBJECT-TYPE 670 SYNTAX Counter32 671 MAX-ACCESS read-only 672 STATUS current 673 DESCRIPTION "A count of successfully transmitted frames on 674 a particular interface for which transmission 675 is inhibited by exactly one collision. 677 A frame that is counted by an instance of this 678 object is also counted by the corresponding 679 instance of either the ifOutUcastPkts, 680 ifOutMulticastPkts, or ifOutBroadcastPkts, 681 and is not counted by the corresponding 682 instance of the dot3StatsMultipleCollisionFrames 683 object." 684 REFERENCE "IEEE 802.3 Layer Management" 685 ::= { dot3StatsEntry 4 } 687 dot3StatsMultipleCollisionFrames OBJECT-TYPE 688 SYNTAX Counter32 689 MAX-ACCESS read-only 690 STATUS current 691 DESCRIPTION "A count of successfully transmitted frames on 692 a particular interface for which transmission 693 is inhibited by more than one collision. 695 A frame that is counted by an instance of this 696 object is also counted by the corresponding 697 instance of either the ifOutUcastPkts, 698 ifOutMulticastPkts, or ifOutBroadcastPkts, 699 and is not counted by the corresponding 700 instance of the dot3StatsSingleCollisionFrames 701 object." 702 REFERENCE "IEEE 802.3 Layer Management" 703 ::= { dot3StatsEntry 5 } 705 dot3StatsSQETestErrors OBJECT-TYPE 706 SYNTAX Counter32 707 MAX-ACCESS read-only 708 STATUS current 709 DESCRIPTION "A count of times that the SQE TEST ERROR 710 message is generated by the PLS sublayer for a 711 particular interface. The SQE TEST ERROR 712 message is defined in section 7.2.2.2.4 of 713 ANSI/IEEE 802.3-1985 and its generation is 714 described in section 7.2.4.6 of the same 715 document." 716 REFERENCE "ANSI/IEEE Std 802.3-1985 Carrier Sense 717 Multiple Access with Collision Detection Access 718 Method and Physical Layer Specifications" 719 ::= { dot3StatsEntry 6 } 721 dot3StatsDeferredTransmissions OBJECT-TYPE 722 SYNTAX Counter32 723 MAX-ACCESS read-only 724 STATUS current 725 DESCRIPTION "A count of frames for which the first 726 transmission attempt on a particular interface 727 is delayed because the medium is busy. 729 The count represented by an instance of this 730 object does not include frames involved in 731 collisions." 732 REFERENCE "IEEE 802.3 Layer Management" 733 ::= { dot3StatsEntry 7 } 735 dot3StatsLateCollisions OBJECT-TYPE 736 SYNTAX Counter32 737 MAX-ACCESS read-only 738 STATUS current 739 DESCRIPTION "The number of times that a collision is 740 detected on a particular interface later than 741 512 bit-times into the transmission of a 742 packet. 744 Five hundred and twelve bit-times corresponds 745 to 51.2 microseconds on a 10 Mbit/s system. A 746 (late) collision included in a count 747 represented by an instance of this object is 748 also considered as a (generic) collision for 749 purposes of other collision-related 750 statistics." 751 REFERENCE "IEEE 802.3 Layer Management" 752 ::= { dot3StatsEntry 8 } 754 dot3StatsExcessiveCollisions OBJECT-TYPE 755 SYNTAX Counter32 756 MAX-ACCESS read-only 757 STATUS current 758 DESCRIPTION "A count of frames for which transmission on a 759 particular interface fails due to excessive 760 collisions." 761 REFERENCE "IEEE 802.3 Layer Management" 762 ::= { dot3StatsEntry 9 } 764 dot3StatsInternalMacTransmitErrors OBJECT-TYPE 765 SYNTAX Counter32 766 MAX-ACCESS read-only 767 STATUS current 768 DESCRIPTION "A count of frames for which transmission on a 769 particular interface fails due to an internal 770 MAC sublayer transmit error. A frame is only 771 counted by an instance of this object if it is 772 not counted by the corresponding instance of 773 either the dot3StatsLateCollisions object, the 774 dot3StatsExcessiveCollisions object, or the 775 dot3StatsCarrierSenseErrors object. 777 The precise meaning of the count represented by 778 an instance of this object is implementation- 779 specific. In particular, an instance of this 780 object may represent a count of transmission 781 errors on a particular interface that are not 782 otherwise counted." 783 REFERENCE "IEEE 802.3 Layer Management" 784 ::= { dot3StatsEntry 10 } 786 dot3StatsCarrierSenseErrors OBJECT-TYPE 787 SYNTAX Counter32 788 MAX-ACCESS read-only 789 STATUS current 790 DESCRIPTION "The number of times that the carrier sense 791 condition was lost or never asserted when 792 attempting to transmit a frame on a particular 793 interface. 795 The count represented by an instance of this 796 object is incremented at most once per 797 transmission attempt, even if the carrier sense 798 condition fluctuates during a transmission 799 attempt." 800 REFERENCE "IEEE 802.3 Layer Management" 801 ::= { dot3StatsEntry 11 } 803 -- { dot3StatsEntry 12 } is not assigned 805 dot3StatsFrameTooLongs OBJECT-TYPE 806 SYNTAX Counter32 807 MAX-ACCESS read-only 808 STATUS current 809 DESCRIPTION "A count of frames received on a particular 810 interface that exceed the maximum permitted 811 frame size. 813 The count represented by an instance of this 814 object is incremented when the frameTooLong 815 status is returned by the MAC service to the 816 LLC (or other MAC user). Received frames for 817 which multiple error conditions obtain are, 818 according to the conventions of IEEE 802.3 819 Layer Management, counted exclusively according 820 to the error status presented to the LLC." 821 REFERENCE "IEEE 802.3 Layer Management" 822 ::= { dot3StatsEntry 13 } 824 -- { dot3StatsEntry 14 } is not assigned 826 -- { dot3StatsEntry 15 } is not assigned 828 dot3StatsInternalMacReceiveErrors OBJECT-TYPE 829 SYNTAX Counter32 830 MAX-ACCESS read-only 831 STATUS current 832 DESCRIPTION "A count of frames for which reception on a 833 particular interface fails due to an internal 834 MAC sublayer receive error. A frame is only 835 counted by an instance of this object if it is 836 not counted by the corresponding instance of 837 either the dot3StatsFrameTooLongs object, the 838 dot3StatsAlignmentErrors object, or the 839 dot3StatsFCSErrors object. 840 The precise meaning of the count represented by 841 an instance of this object is implementation- 842 specific. In particular, an instance of this 843 object may represent a count of receive errors 844 on a particular interface that are not 845 otherwise counted." 846 REFERENCE "IEEE 802.3 Layer Management" 847 ::= { dot3StatsEntry 16 } 849 dot3StatsEtherChipSet OBJECT-TYPE 850 SYNTAX OBJECT IDENTIFIER 851 MAX-ACCESS read-only 852 STATUS current 853 DESCRIPTION "This object contains an OBJECT IDENTIFIER 854 which identifies the chipset used to 855 realize the interface. Ethernet-like 856 interfaces are typically built out of 857 several different chips. The MIB implementor 858 is presented with a decision of which chip 859 to identify via this object. The implementor 860 should identify the chip which is usually 861 called the Medium Access Control chip. 862 If no such chip is easily identifiable, 863 the implementor should identify the chip 864 which actually gathers the transmit 865 and receive statistics and error 866 indications. This would allow a 867 manager station to correlate the 868 statistics and the chip generating 869 them, giving it the ability to take 870 into account any known anomalies 871 in the chip." 872 ::= { dot3StatsEntry 17 } 874 dot3StatsSymbolErrors OBJECT-TYPE 875 SYNTAX Counter32 876 MAX-ACCESS read-only 877 STATUS current 878 DESCRIPTION "The number of times there was an invalid data 879 symbol when a valid carrier was present on a 880 particular interface. 882 The count represented by an instance of this 883 object is incremented at most once per carrier 884 event, even if multiple symbol errors occur 885 during the carrier event." 886 REFERENCE "IEEE 802.3u-1995 10 & 100 Mb/s Management" 887 ::= { dot3StatsEntry 18 } 889 -- the Ethernet-like Collision Statistics group 891 -- Implementation of this group is optional; it is appropriate 892 -- for all systems which have the necessary metering 894 dot3CollTable OBJECT-TYPE 895 SYNTAX SEQUENCE OF Dot3CollEntry 896 MAX-ACCESS not-accessible 897 STATUS current 898 DESCRIPTION "A collection of collision histograms for a 899 particular set of interfaces." 900 ::= { dot3 5 } 902 dot3CollEntry OBJECT-TYPE 903 SYNTAX Dot3CollEntry 904 MAX-ACCESS not-accessible 905 STATUS current 906 DESCRIPTION "A cell in the histogram of per-frame 907 collisions for a particular interface. An 908 instance of this object represents the 909 frequency of individual MAC frames for which 910 the transmission (successful or otherwise) on a 911 particular interface is accompanied by a 912 particular number of media collisions." 913 INDEX { ifIndex, dot3CollCount } 914 ::= { dot3CollTable 1 } 916 Dot3CollEntry ::= 917 SEQUENCE { 918 dot3CollCount INTEGER, 919 dot3CollFrequencies Counter32 920 } 922 -- { dot3CollEntry 1 } is no longer in use 924 dot3CollCount OBJECT-TYPE 925 SYNTAX INTEGER (1..16) 926 MAX-ACCESS not-accessible 927 STATUS current 928 DESCRIPTION "The number of per-frame media collisions for 929 which a particular collision histogram cell 930 represents the frequency on a particular 931 interface." 932 ::= { dot3CollEntry 2 } 934 dot3CollFrequencies OBJECT-TYPE 935 SYNTAX Counter32 936 MAX-ACCESS read-only 937 STATUS current 938 DESCRIPTION "A count of individual MAC frames for which the 939 transmission (successful or otherwise) on a 940 particular interface occurs after the 941 frame has experienced exactly the number 942 of collisions in the associated 943 dot3CollCount object. 945 For example, a frame which is transmitted 946 on interface 77 after experiencing 947 exactly 4 collisions would be indicated 948 by incrementing only dot3CollFrequencies.77.4. 950 No other instance of dot3CollFrequencies would 951 be incremented in this example." 952 ::= { dot3CollEntry 3 } 954 -- 802.3 Tests 956 dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } 958 dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } 960 -- TDR Test 962 dot3TestTdr OBJECT-IDENTITY 963 STATUS current 964 DESCRIPTION "The Time-Domain Reflectometry (TDR) test is 965 specific to ethernet-like interfaces of type 966 10Base5 and 10Base2. The TDR value may be 967 useful in determining the approximate distance 968 to a cable fault. It is advisable to repeat 969 this test to check for a consistent resulting 970 TDR value, to verify that there is a fault. 972 A TDR test returns as its result the time 973 interval, measured in 10 MHz ticks or 100 nsec 974 units, between the start of TDR test 975 transmission and the subsequent detection of a 976 collision or deassertion of carrier. On 977 successful completion of a TDR test, the result 978 is stored as the value of an appropriate 979 instance of an appropriate vendor specific MIB 980 object, and the OBJECT IDENTIFIER of that 981 instance is stored in the appropriate instance 982 of the appropriate test result code object 983 (thereby indicating where the result has been 984 stored). 985 ::= { dot3Tests 1 } 987 -- Loopback Test 989 dot3TestLoopBack OBJECT-IDENTITY 990 STATUS current 991 DESCRIPTION "This test configures the MAC chip and executes 992 an internal loopback test of memory, data paths, 993 and the MAC chip logic. This loopback test can 994 only be executed if the interface is offline. 995 Once the test has completed, the MAC chip should 996 be reinitialized for network operation, but it 997 should remain offline. 999 If an error occurs during a test, the 1000 appropriate test result object will be set 1001 to indicate a failure. The two OBJECT 1002 IDENTIFIER values dot3ErrorInitError and 1003 dot3ErrorLoopbackError may be used to provided 1004 more information as values for an appropriate 1005 test result code object." 1006 ::= { dot3Tests 2 } 1008 dot3ErrorInitError OBJECT-IDENTITY 1009 STATUS current 1010 DESCRIPTION "Couldn't initialize MAC chip for test." 1011 ::= { dot3Errors 1 } 1013 dot3ErrorLoopbackError OBJECT-IDENTITY 1014 STATUS current 1015 DESCRIPTION "Expected data not received (or not received 1016 correctly) in loopback test." 1017 ::= { dot3Errors 2 } 1019 -- 802.3 Hardware Chipsets 1021 -- The object dot3StatsEtherChipSet is provided to 1022 -- identify the MAC hardware used to communicate on an 1023 -- interface. The following hardware chipsets are 1024 -- provided: 1026 dot3ChipSets OBJECT IDENTIFIER ::= { dot3 8 } 1028 dot3ChipSetAMD OBJECT IDENTIFIER ::= { dot3ChipSets 1 } 1030 dot3ChipSetAMD7990 OBJECT-IDENTITY 1031 STATUS current 1032 DESCRIPTION "The authoritative identifier for the Advanced 1033 Micro Devices Am7990 Local Area Network 1034 Controller for Ethernet (LANCE)." 1035 ::= { dot3ChipSetAMD 1 } 1037 dot3ChipSetAMD79900 OBJECT-IDENTITY 1038 STATUS current 1039 DESCRIPTION "The authoritative identifier for the Advanced 1040 Micro Devices Am79900 chip." 1041 ::= { dot3ChipSetAMD 2 } 1043 dot3ChipSetAMD79C940 OBJECT-IDENTITY 1044 STATUS current 1045 DESCRIPTION "The authoritative identifier for the Advanced 1046 Micro Devices am79C940 Media Access Controller 1047 for Ethernet (MACE)." 1048 ::= { dot3ChipSetAMD 3 } 1050 dot3ChipSetIntel OBJECT IDENTIFIER ::= { dot3ChipSets 2 } 1052 dot3ChipSetIntel82586 OBJECT-IDENTITY 1053 STATUS current 1054 DESCRIPTION "The authoritative identifier for the Intel 1055 82586 IEEE 802.3 Ethernet LAN Coprocessor." 1056 ::= { dot3ChipSetIntel 1 } 1058 dot3ChipSetIntel82596 OBJECT-IDENTITY 1059 STATUS current 1060 DESCRIPTION "The authoritative identifier for the Intel 1061 82596 High-Performance 32-Bit Local Area Network 1062 Coprocessor." 1063 ::= { dot3ChipSetIntel 2 } 1065 dot3ChipSetSeeq OBJECT IDENTIFIER ::= { dot3ChipSets 3 } 1067 dot3ChipSetSeeq8003 OBJECT-IDENTITY 1068 STATUS current 1069 DESCRIPTION "The authoritative identifier for the SEEQ 1070 8003 chip set." 1071 ::= { dot3ChipSetSeeq 1 } 1073 dot3ChipSetNational OBJECT IDENTIFIER ::= { dot3ChipSets 4 } 1075 dot3ChipSetNational8390 OBJECT-IDENTITY 1076 STATUS current 1077 DESCRIPTION "The authoritative identifier for the National 1078 Semiconductor DP8390 Network Interface 1079 Controller." 1080 ::= { dot3ChipSetNational 1 } 1082 dot3ChipSetNationalSonic OBJECT-IDENTITY 1083 STATUS current 1084 DESCRIPTION "The authoritative identifier for the National 1085 Semiconductor DP83932 Systems-Oriented Network 1086 Interface Controller (SONIC)." 1087 ::= { dot3ChipSetNational 2 } 1089 dot3ChipSetFujitsu OBJECT IDENTIFIER ::= { dot3ChipSets 5 } 1091 dot3ChipSetFujitsu86950 OBJECT-IDENTITY 1092 STATUS current 1093 DESCRIPTION "The authoritative identifier for the Fujitsu 1094 86950 chip." 1095 ::= { dot3ChipSetFujitsu 1 } 1097 dot3ChipSetDigital OBJECT IDENTIFIER ::= { dot3ChipSets 6 } 1099 dot3ChipSetDigitalDC21040 OBJECT-IDENTITY 1100 STATUS current 1101 DESCRIPTION "The authoritative identifier for the Digital 1102 DC21040 chip." 1103 ::= { dot3ChipSetDigital 1 } 1105 -- For those chipsets not represented above, OBJECT IDENTIFIER 1106 -- assignment is required in other documentation, e.g., 1107 -- assignment within that part of the registration tree 1108 -- deletaged to individual enterprises (see RFC1155). 1110 -- conformance information 1112 etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 } 1114 etherGroups OBJECT IDENTIFIER ::= { etherConformance 1 } 1115 etherCompliances OBJECT IDENTIFIER ::= { etherConformance 2 } 1117 -- compliance statements 1119 etherCompliance MODULE-COMPLIANCE 1120 STATUS current 1121 DESCRIPTION "The compliance statement for managed network 1122 entities which have ethernet-like network 1123 interfaces." 1125 MODULE -- this module 1126 MANDATORY-GROUPS { etherStatsGroup } 1128 GROUP etherCollisionTableGroup 1129 DESCRIPTION "This group is optional. It is appropriate 1130 for all systems which have the necessary 1131 metering Implementation in such systems is 1132 highly recommended." 1133 ::= { etherCompliances 1 } 1135 ether100MbsCompliance MODULE-COMPLIANCE 1136 STATUS current 1137 DESCRIPTION "The compliance statement for managed network 1138 entities which have 100 Mb/sec ethernet-like 1139 network interfaces." 1141 MODULE -- this module 1142 MANDATORY-GROUPS { etherStats100MbsGroup } 1144 GROUP etherCollisionTableGroup 1145 DESCRIPTION "This group is optional. It is appropriate 1146 for all systems which have the necessary 1147 metering Implementation in such systems is 1148 highly recommended." 1149 ::= { etherCompliances 2 } 1151 -- units of conformance 1153 etherStatsGroup OBJECT-GROUP 1154 OBJECTS { dot3StatsIndex, 1155 dot3StatsAlignmentErrors, 1156 dot3StatsFCSErrors, 1157 dot3StatsSingleCollisionFrames, 1158 dot3StatsMultipleCollisionFrames, 1159 dot3StatsSQETestErrors, 1160 dot3StatsDeferredTransmissions, 1161 dot3StatsLateCollisions, 1162 dot3StatsExcessiveCollisions, 1163 dot3StatsInternalMacTransmitErrors, 1164 dot3StatsCarrierSenseErrors, 1165 dot3StatsFrameTooLongs, 1166 dot3StatsInternalMacReceiveErrors, 1167 dot3StatsEtherChipSet 1168 } 1169 STATUS current 1170 DESCRIPTION "A collection of objects providing information 1171 applicable to all ethernet-like network 1172 interfaces." 1173 ::= { etherGroups 1 } 1175 etherCollisionTableGroup OBJECT-GROUP 1176 OBJECTS { dot3CollFrequencies 1177 } 1178 STATUS current 1179 DESCRIPTION "A collection of objects providing a histogram 1180 of packets successfully transmitted after 1181 experiencing exactly N collisions." 1182 ::= { etherGroups 2 } 1184 etherStats100MbsGroup OBJECT-GROUP 1185 OBJECTS { dot3StatsIndex, 1186 dot3StatsAlignmentErrors, 1187 dot3StatsFCSErrors, 1188 dot3StatsSingleCollisionFrames, 1189 dot3StatsMultipleCollisionFrames, 1190 dot3StatsDeferredTransmissions, 1191 dot3StatsLateCollisions, 1192 dot3StatsExcessiveCollisions, 1193 dot3StatsInternalMacTransmitErrors, 1194 dot3StatsCarrierSenseErrors, 1195 dot3StatsFrameTooLongs, 1196 dot3StatsInternalMacReceiveErrors, 1197 dot3StatsEtherChipSet, 1198 dot3StatsSymbolErrors 1199 } 1200 STATUS current 1201 DESCRIPTION "A collection of objects providing information 1202 applicable to 100 Mb/sec ethernet-like network 1203 interfaces." 1204 ::= { etherGroups 3 } 1206 END 1208 6. Intellectual Property 1210 The IETF takes no position regarding the validity or scope of any 1211 intellectual property or other rights that might be claimed to 1212 pertain to the implementation or use of the technology described in 1213 this document or the extent to which any license under such rights 1214 might or might not be available; neither does it represent that it 1215 has made any effort to identify any such rights. Information on the 1216 IETF's procedures with respect to rights in standards-track and 1217 standards-related documentation can be found in BCP-11. Copies of 1218 claims of rights made available for publication and any assurances of 1219 licenses to be made available, or the result of an attempt made to 1220 obtain a general license or permission for the use of such 1221 proprietary rights by implementors or users of this specification can 1222 be obtained from the IETF Secretariat. 1224 The IETF invites any interested party to bring to its attention any 1225 copyrights, patents or patent applications, or other proprietary 1226 rights which may cover technology that may be required to practice 1227 this standard. Please address the information to the IETF Executive 1228 Director. 1230 7. Acknowledgements 1232 This document was produced by the 802.3 Hub MIB Working Group. 1234 This document is almost completely based on both the Standard 1235 Ethernet MIB, RFC 1623 [10], and the Proposed Standard Ethernet MIB 1236 using the SNMPv2 SMI, RFC 1650 [11], both of which were edited by 1237 Frank Kastenholz of FTP Software and produced by the Ethernet MIB 1238 Working Group. This document extends those documents by providing 1239 support for 100 Mb/sec ethernet interfaces as outlined in [6]. 1241 RFC 1623 and RFC 1650, in turn, are based on the Draft Standard 1242 Ethernet MIB, RFC 1398 [9], also edited by Frank Kastenholz and 1243 produced by the Ethernet MIB Working Group. 1245 RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB, 1246 RFC 1284 [8], which was edited by John Cook of Chipcom and produced 1247 by the Transmission MIB Working Group. The Ethernet MIB Working 1248 Group gathered implementation experience of the variables specified 1249 in RFC 1284 and used that information to develop this revised MIB. 1251 RFC 1284, in turn, is based on a document written by Frank 1252 Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management 1253 Draft M compatible MIB for TCP/IP Networks [7]. This document has 1254 been modestly reworked, initially by the SNMP Working Group, and then 1255 by the Transmission Working Group, to reflect the current conventions 1256 for defining objects for MIB interfaces. James Davin, of the MIT 1257 Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN 1258 Systems, contributed to later drafts of this memo. Marshall Rose of 1259 Performance Systems International, Inc. converted the document into 1260 its current concise format. Anil Rijsinghani of DEC contributed text 1261 that more adequately describes the TDR test. Thanks to Frank 1262 Kastenholz of Interlan and Louis Steinberg of IBM for their 1263 experimentation. 1265 8. References 1267 [1] Information processing systems - Open Systems Interconnection - 1268 Specification of Abstract Syntax Notation One (ASN.1), 1269 International Organization for Standardization, International 1270 Standard 8824, December 1987. 1272 [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1273 S. Waldbusser, "Structure of Management Information for Version 1274 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 1275 January 1996. 1277 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1278 S. Waldbusser, "Textual Conventions for Version 2 of the Simple 1279 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1281 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1282 S. Waldbusser, "Conformance Statements for Version 2 of the 1283 Simple Network Management Protocol (SNMPv2)", RFC 1904, 1284 January 1996. 1286 [5] IEEE, IEEE 802.3 Layer Management, November 1988. 1288 [6] IEEE, IEEE 802.3u-1995, "10 & 100 Mb/s Management," Section 30, 1289 Supplement to IEEE Std 802.3, October 26, 1995. 1291 [7] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible 1292 MIB for TCP/IP Networks", electronic mail message to mib- 1293 wg@nnsc.nsf.net, 9 June 1989. 1295 [8] Cook, J., "Definitions of Managed Objects for Ethernet-Like 1296 Interface Types", RFC 1284, Chipcom Corporation, December 1991. 1298 [9] Kastenholz, F., "Definitions of Managed Objects for the 1299 Ethernet-like Interface Types", RFC 1398, FTP Software, Inc., 1300 January 1993. 1302 [10] Kastenholz, F., "Definitions of Managed Objects for the 1303 Ethernet-like Interface Types", RFC 1623, FTP Software, Inc., 1304 May 1994. 1306 [11] Kastenholz, F., "Definitions of Managed Objects for the 1307 Ethernet-like Interface Types using SMIv2", RFC 1650, 1308 FTP Software, Inc., August 1994. 1310 [12] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces 1311 Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, 1312 January 1994. 1314 [13] Bradner, S., "Key words for use in RFCs to Indicate 1315 Requirements Levels", BCP 14, RFC 2119, March 1997. 1317 [14] deGraaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and 1318 S. Roberts, "Definitions of Managed Objects for IEEE 802.3 1319 Medium Attachment Units (MAUs) using SMIv2", RFCXXXX, 1320 3Com Corporation, Madge Networks (Israel) Ltd., Cisco Systems 1321 Inc., Cisco Systems Inc., Farallon Computing Inc., October 1997. 1323 [15] Kastenholz, F., "Implementation Notes and Experience for The 1324 Internet Ethernet MIB", RFC 1369, FTP Software, October 1992. 1326 9. Security Considerations 1328 Certain management information defined in this MIB may be considered 1329 sensitive in some network environments. Therefore, authentication of 1330 received SNMP requests and controlled access to management 1331 information should be employed in such environments. The method for 1332 this authentication is a function of the SNMP Administrative 1333 Framework, and has not been expanded by this MIB. 1335 10. Author's Addresses 1337 John Flick 1338 Hewlett-Packard Company 1339 8000 Foothills Blvd. M/S 5556 1340 Roseville, CA 95747-5556 1342 Phone: +1 916 785 4018 1343 Email: johnf@hprnd.rose.hp.com 1345 Jeffrey Johnson 1346 RedBack Networks 1347 2570 North First Street, Suite 410 1348 San Jose, CA, 95131, USA 1350 Phone: +1 408 571 2699 1351 EMail: jeff@redbacknetworks.com 1353 Frank Kastenholz 1354 FTP Software, Inc. 1355 2 High Street 1356 North Andover, Mass, USA 01845 1358 Phone: +1 508 685 4000 1359 EMail: kasten@ftp.com 1361 11. Full Copyright Statement 1363 This document and translations of it may be copied and furnished to 1364 others, and derivative works that comment on or otherwise explain it 1365 or assist in its implementation may be prepared, copied, published 1366 and distributed, in whole or in part, without restriction of any 1367 kind, provided that the above copyright notice and this paragraph are 1368 included on all such copies and derivative works. However, this 1369 document itself may not be modified in any way, such as by removing 1370 the copyright notice or references to the Internet Society or other 1371 Internet organizations, except as needed for the purpose of 1372 developing Internet standards in which case the procedures for 1373 copyrights defined in the Internet Standards process must be 1374 followed, or as required to translate it into languages other than 1375 English. 1377 The limited permissions granted above are perpetual and will not be 1378 revoked by the Internet Society or its successors or assigns. 1380 This document and the information contained herein is provided on an 1381 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1382 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1383 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1384 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1385 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1387 Table of Contents 1389 1. Introduction ................................................ 2 1390 2. The SNMP Network Management Framework ...................... 2 1391 2.1. Object Definitions ....................................... 2 1392 3. Change Log ................................................. 2 1393 4. Overview ................................................... 3 1394 4.1. Relation to MIB-2 ........................................ 4 1395 4.2. Relation to the Interfaces MIB ........................... 4 1396 4.2.1. Layering Model ......................................... 5 1397 4.2.2. Virtual Circuits ....................................... 5 1398 4.2.3. ifTestTable ............................................ 5 1399 4.2.4. ifRcvAddressTable ...................................... 5 1400 4.2.5. ifPhysAddress .......................................... 6 1401 4.2.6. ifType ................................................. 6 1402 4.2.7. Specific Interface MIB Objects ......................... 7 1403 4.3. Relation to the 802.3 MAU MIB ............................ 10 1404 4.4. Mapping of IEEE 802.3 Managed Objects .................... 10 1405 5. Definitions ................................................ 13 1406 6. Intellectual Property ...................................... 28 1407 7. Acknowledgements ........................................... 28 1408 8. References ................................................. 29 1409 9. Security Considerations .................................... 30 1410 10. Author's Addresses ........................................ 30 1411 11. Full Copyright Statement .................................. 31