idnits 2.17.1 draft-ietf-vgmib-interfaces-mib-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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. ** 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. ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 1996) is 10284 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) == Unused Reference: '3' is defined on line 1381, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1387, but no explicit reference was found in the text -- 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. '6' ** Obsolete normative reference: RFC 1573 (ref. '7') (Obsoleted by RFC 2233) ** Obsolete normative reference: RFC 1643 (ref. '8') (Obsoleted by RFC 3638) ** Obsolete normative reference: RFC 1650 (ref. '9') (Obsoleted by RFC 2358) ** Downref: Normative reference to an Historic RFC: RFC 1749 (ref. '11') Summary: 17 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft IEEE 802.12 Interface MIB February 22 1996 4 Definitions of Managed Objects for IEEE 802.12 Interfaces 6 February 22, 1996 8 John Flick 10 Hewlett Packard Company 11 8000 Foothills Blvd. M/S 5556 12 Roseville, CA 95747-5556 14 johnf@hprnd.rose.hp.com 16 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 To learn the current status of any Internet-Draft, please check the 31 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 1. Introduction 38 This memo defines a portion of the Management Information Base (MIB) 39 for use with network management protocols in TCP/IP-based internets. 40 In particular, it defines objects for managing network interfaces 41 based on IEEE 802.12. 43 2. Object Definitions 45 Management information is viewed as a collection of managed objects, 46 residing in a virtual information store, termed the Management 47 Information Base (MIB). Collections of related objects are defined 48 in MIB modules. MIB modules are written using a subset of Abstract 49 Syntax Notation One (ASN.1) [1] termed the Structure of Management 50 Information (SMI) [2]. In particular, each object type is named by 51 an OBJECT IDENTIFIER, an administratively assigned name. The object 52 type together with an object instance serves to uniquely identify a 53 specific instantiation of the object. For human convenience, we 54 often use a textual string, termed the descriptor, to refer to the 55 object type. 57 3. Overview 59 Instances of these object types represent attributes of an interface 60 to an IEEE 802.12 communications medium. At present, IEEE 802.12 61 media are identified by one value of the ifType object in the 62 Internet-standard MIB: 64 ieee80212(55) 66 For this interface, the value of the ifSpecific variable in the MIB- 67 II [5] has the OBJECT IDENTIFIER value: 69 dot12MIB OBJECT IDENTIFIER ::= { transmission TBD } 71 The values for the ifType object are defined by the IANAifType 72 textual convention. The Internet Assigned Number Authority (IANA) is 73 responsible for the assignment of all Internet numbers, including new 74 ifType values. Therefore, IANA is responsible for maintaining the 75 definition of this textual convention. The current definition of the 76 IANAifType textual convention is available from IANA's World Wide Web 77 server at: 79 <> 81 The definitions presented here are based on the IEEE Standard 82 802.12-1995, [6] Clause 13 "Layer management functions and services", 83 and Annex C "GDMO Specifications for Demand Priority Managed 84 Objects". Implementors of these MIB objects should note that the 85 IEEE document explicitly describes (in the form of Pascal pseudocode) 86 when, where, and how various MAC attributes are measured. The IEEE 87 document also describes the effects of MAC actions that may be 88 invoked by manipulating instances of the MIB objects defined here. 90 To the extent that some of the attributes defined in [6] are 91 represented by previously defined objects in the Internet-standard 92 MIB [5] or in the Evolution of the Interfaces Group of MIB-II [7], 93 such attributes are not redundantly represented by objects defined in 94 this memo. Among the attributes represented by objects defined in 95 other memos are the number of octets transmitted or received on a 96 particular interface, the MAC address of an interface, and multicast 97 information associated with an interface. 99 3.1. MAC Addresses 101 All representations of MAC addresses in this MIB module, and in other 102 related MIB modules (like RFC 1573), are in "canonical" order defined 103 by 802.1a, i.e., as if it were transmitted least significant bit 104 first. This is true even if the interface is operating in token ring 105 framing mode, which requires MAC addresses to be transmitted most 106 significant bit first. 108 3.2. Relation to RFC 1213 110 This section applies only when this MIB is used in conjunction with 111 the "old" (i.e., pre-RFC 1573) interface group. 113 The relationship between an IEEE 802.12 interface and an interface in 114 the context of the Internet-standard MIB is one-to-one. As such, the 115 value of an ifIndex object instance can be directly used to identify 116 corresponding instances of the objects defined herein. 118 3.3. Relation to RFC 1573 120 RFC 1573, the Interface MIB Evolution, requires that any MIB which is 121 an adjunct of the Interface MIB, clarify specific areas within the 122 Interface MIB. These areas are intentionally left vague in RFC 1573 123 to avoid over constraining the MIB, thereby precluding management of 124 certain media-types. 126 An agent which implements this MIB module must support the 127 ifGeneralGroup, ifStackGroup, ifHCPacketGroup, and ifRcvAddressGroup 128 of RFC 1573. 130 Section 3.3 of RFC 1573 enumerates several areas which a media- 131 specific MIB must clarify. In addition, there are some objects in 132 RFC 1573 for which additional clarification of how to apply them to 133 an IEEE 802.12 interface would be helpful. Each of these areas is 134 addressed in a following subsection. The implementor is referred to 135 RFC 1573 in order to understand the general intent of these areas. 137 3.3.1. Layering Model 139 For the typical usage of this MIB module, there will be no sub-layers 140 "above" or "below" the 802.12 Interface. However, this MIB module 141 does not preclude such layering. 143 3.3.2. Virtual Circuits 145 This medium does not support virtual circuits and this area is not 146 applicable to this MIB. 148 3.3.3. ifTestTable 150 This MIB does not define any tests for media instrumented by this 151 MIB. Implementation of the ifTestTable is not required. An 152 implementation may optionally implement the ifTestTable to execute 153 vendor specific tests. 155 3.3.4. ifRcvAddressTable 157 This table contains all IEEE addresses, unicast, multicast, and 158 broadcast, for which this interface will receive packets and forward 159 them up to a higher layer entity for consumption. In addition, when 160 the interface is using 802.5 framing mode, the ifRcvAddressTable will 161 contain the functional address mask. 163 In the event that the interface is part of a MAC bridge, this table 164 does not include unicast addresses which are accepted for possible 165 forwarding out some other port. This table is explicitly not 166 intended to provide a bridge address filtering mechanism. 168 3.3.5. ifPhysAddress 169 This object contains the IEEE 802.12 address which is placed in the 170 source-address field of any frames that originate at this interface. 171 Usually this will be kept in ROM on the interface hardware. Some 172 systems may set this address via software. 174 In a system where there are several such addresses the designer has a 175 tougher choice. The address chosen should be the one most likely to 176 be of use to network management (e.g. the address placed in ARP 177 responses for systems which are primarily IP systems). 179 If the designer truly can not choose, use of the factory-provided ROM 180 address is suggested. 182 If the address can not be determined, an octet string of zero length 183 should be returned. 185 The address is stored in binary in this object. The address is 186 stored in "canonical" bit order, that is, the Group Bit is positioned 187 as the low-order bit of the first octet. Thus, the first byte of a 188 multicast address would have the bit 0x01 set. This is true even 189 when the interface is using token ring framing mode, which transmits 190 addresses high-order bit first. 192 3.3.6. Specific Interface MIB Objects 194 The following table provides specific implementation guidelines for 195 the interface group objects in the conformance groups listed above. 197 Object Use for an 802.12 Interface 199 ifIndex Each 802.12 interface is represented by an 200 ifEntry. Interface tables in this MIB 201 module are indexed by ifIndex. 203 ifDescr Refer to [7]. 205 ifType The IANA reserved value for 802.12 - 55. 207 ifMtu The value of ifMtu on an 802.12 interface 208 will depend on the type of framing that is 209 in use on that interface. Changing the 210 dot12DesiredFramingType may have the effect 211 of changing ifMtu after the next time that 212 the interface trains. When 213 dot12CurrentFramingType is equal to 214 frameType88023, ifMtu will be equal to 215 1500. When dot12CurrentFramingType is 216 equal to frameType88025, ifMtu will be 217 4464. 219 ifSpeed The speed of the interface in bits per 220 second. For current 802.12 221 implementations, this will be equal to 222 100,000,000 (100 million). 224 ifPhysAddress See Section 3.3.5. 226 ifAdminStatus Write access is not required. Support for 227 'testing' is not required. Setting this 228 object to 'up' will cause dot12Commands to 229 be set to 'open'. Setting this object to 230 'down' will cause dot12Commands to be set 231 to 'close'. Setting dot12Commands to 232 'open' will set this object to 'up'. 233 Setting dot12Commands to 'close' will set 234 this object to 'down'. Setting 235 dot12Commands to 'reset' will have no 236 effect on this object. 238 ifOperStatus When dot12Status is equal to 'opened', this 239 object will be equal to 'up'. When 240 dot12Status is equal to 'closed', 'opening', 241 'openFailure' or 'linkFailure', this object 242 will be equal to 'down'. Support for 243 'testing' is not required, but may be used 244 to indicate that a vendor specific test is 245 in progress. The value 'dormant' has no 246 meaning for an IEEE 802.12 interface. 248 ifLastChange Refer to [7]. 250 ifInOctets The number of octets in valid MAC frames 251 received on this interface, including the 252 MAC header and FCS. 254 ifInUcastPkts Refer to [7]. 256 ifInDiscards Refer to [7]. 258 ifInErrors The sum for this interface of 259 dot12InIPMErrors, 260 dot12InOversizeFrameErrors, 261 dot12InDataErrors, and any additional 262 internal errors that may occur in an 263 implementation. 265 ifInUnknownProtos Refer to [7]. 267 ifOutOctets The number of octets transmitted in MAC 268 frames on this interface, including the MAC 269 header and FCS. 271 ifOutUcastPkts Refer to [7]. 273 ifOutDiscards Refer to [7]. 275 ifOutErrors The number of implementation-specific 276 internal transmit errors on this interface. 278 ifName Locally-significant textual name for the 279 interface (e.g. vg0). 281 ifInMulticastPkts Refer to [7]. When dot12CurrentFramingType 282 is frameType88025, this count includes 283 packets addressed to functional addresses. 285 ifInBroadcastPkts Refer to [7]. 287 ifOutMulticastPkts Refer to [7]. When dot12CurrentFramingType 288 is frameType88025, this count includes 289 packets addressed to functional addresses. 291 ifOutBroadcastPkts Refer to [7]. 293 ifHCInOctets 64-bit version of ifInOctets. 295 ifHCOutOctets 64-bit version of ifOutOctets 297 ifHC*Pkts Not required for 100 MBit interfaces. 298 Future IEEE 802.12 interfaces which operate 299 at higher speeds may require implementation 300 of these counters, but such interfaces are 301 beyond the scope of this memo. 303 ifLinkUpDownTrapEnable Refer to [7]. Default is 'enabled'. 305 ifHighSpeed The speed of the interface in millions of 306 bits per second. For current 802.12 307 implementations, this will be equal to 100. 309 ifPromiscuousMode Reflects whether the interface has 310 successfully trained and is currently 311 operating in promiscuous mode. 312 dot12DesiredPromiscStatus is used to select 313 the promiscuous mode to be requested in the 314 next training attempt. Setting 315 ifPromiscuousMode will update 316 dot12DesiredPromiscStatus and cause the 317 interface to attempt to retrain using the 318 new promiscuous mode. After the interface 319 has retrained, ifPromiscuousMode will 320 reflect the mode that is in use, not the 321 mode that was requested. 323 ifConnectorPresent This will normally be 'true'. 325 ifStackHigherLayer Refer to section 3.3.1 326 ifStackLowerLayer 327 ifStackStatus 329 ifRcvAddressAddress Refer to section 3.3.4. 330 ifRcvAddressStatus 331 ifRcvAddressType 333 3.4. Relation to RFC 1643, RFC 1650, and RFC 1748 335 An IEEE 802.12 interface can be configured to operate in either 336 ethernet or token ring framing mode. An IEEE 802.12 interface uses 337 the frame format for the configured framing mode, but does not use 338 the media access protocol for ethernet or token ring. Instead, IEEE 339 802.12 defines its own media access protocol, the Demand Priority 340 Access Method (DPAM). 342 There are existing standards-track MIB modules for instrumenting 343 ethernet-like interfaces and token ring interfaces. At the time of 344 this writing, they are: STD 50, RFC 1643, "Definitions of Managed 345 Objects for Ethernet-like Interface Types" [8]; RFC 1650, 346 "Definitions of Managed Objects for Ethernet-like Interface Types 347 using SMIv2" [9]; and RFC 1748, "IEEE 802.5 MIB using SMIv2" [10]. 348 These MIB modules are designed to instrument the media access 349 protocol for these respective technologies. Since IEEE 802.12 350 interfaces do not implement either of these media access protocols, 351 an agent should not implement RFC 1643, RFC 1650, or RFC 1748 for 352 IEEE 802.12 interfaces. 354 3.5. Relation to RFC 1749 356 When an IEEE 802.12 interface is operating in token ring framing 357 mode, and the end node supports token ring source routing, the agent 358 should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB 360 [11] for those interfaces. 362 3.6. Master Mode Operation 364 In an IEEE 802.12 network, "master" devices act as network 365 controllers to decide when to grant requesting end-nodes permission 366 to transmit. These master devices may be repeaters, or other active 367 controller devices such as switches. 369 Devices which do not act as network controllers, such as end-nodes or 370 passive switches, are considered to be operating in "slave" mode. 372 The dot12ControlMode object indicates if the interface is operating 373 in master mode or slave mode. 375 3.7. Normal and High Priority Counters 377 The IEEE 802.12 interface MIB does not provide normal priority 378 transmit counters. Standardization of normal priority transmit 379 counters could not be justified -- ifOutUcastPkts, 380 ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets, 381 dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets should 382 suffice. More precisely, the number of normal priority frames 383 transmitted can be calculated as: 385 outNormPriorityFrames = ifOutUcastPkts + 386 ifOutMulticastPkts + 387 ifOutBroadcastPkts - 388 dot12OutHighPriorityFrames 390 The number of normal priority octets transmitted can be calculated 391 as: 393 outNormPriorityOctets = ifOutOctets - 394 dot12OutHighPriorityOctets 396 On the other hand, normal priority receive counters are provided. 397 The main reason for this is that the normal priority and high 398 priority counters include errored frames, whereas the ifIn*Pkts and 399 ifInOctets do not include errored frames. dot12InNormPriorityFrames 400 could be calculated, but the calculation is tedious: 402 inNormPriorityFrames = ifInUcastPkts + 403 ifInMulticastPkts + 404 ifInBroadcastPkts + 405 dot12InNullAddressedFrames + 406 ifInErrors + 407 ifInDiscards + 408 ifInUnknownProtos - 409 dot12InHighPriorityFrames 411 dot12InNormPriorityOctets includes octets in unreadable frames, which 412 is not available elsewhere. The number of octets in unreadable 413 frames can be calculated as: 415 octetsInUnreadableFrames = dot12InNormPriorityOctets + 416 dot12InHighPriorityOctets - 417 ifInOctets 419 Also, the total traffic at this interface can be calculated as: 421 traffic = dot12InNormPriorityOctets + 422 dot12InHighPriorityOctets + 423 ifOutOctets 425 In other words, the normal priority receive counters were deemed 426 useful, whereas the normal priority transmit counters can be easily 427 calculated from other available counters. 429 3.8. IEEE 802.12 Training Frames 431 Training frames are special MAC frames that are used only during link 432 initialization. Training frames are initially constructed by the 433 device at the lower end of a link, which is the slave mode device for 434 the link. The training frame format is as follows: 436 +----+----+------------+--------------+----------+-----+ 437 | DA | SA | Req Config | Allow Config | Data | FCS | 438 +----+----+------------+--------------+----------+-----+ 440 DA = destination address (six octets) 441 SA = source address (six octets) 442 Req Config = requested configuration (2 octets) 443 Allow Config = allowed configuration (2 octets) 444 Data = data (594 to 675 octets) 445 FCS = frame check sequence (4 octets) 447 Training frames are always sent with a null destination address. To 448 pass training, an end node must use its source address in the source 449 address field of the training frame. A repeater may use a non-null 450 source address if it has one, or it may use a null source address. 452 The requested configuration field allows the slave mode device to 453 inform the master mode device about itself and to request 454 configuration options. The training response frame from the master 455 mode device contains the slave mode device's requested configuration 456 from the training request frame. The currently defined format of the 457 requested configuration field as defined in the IEEE Standard 458 802.12-1995 standard is shown below. Please refer to the most 459 current version of the IEEE document for a more up to date 460 description of this field. In particular, the reserved bits may be 461 used in later versions of the standard. 463 First Octet: Second Octet: 465 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 466 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 467 |v|v|v|r|r|r|r|r| |r|r|r|F|F|P|P|R| 468 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 470 vvv: The version of the 802.12 training protocol with which 471 the training initiator is compliant. The current version 472 is 100. 473 r: Reserved bits (set to zero) 474 FF: 00 = frameType88023 475 01 = frameType88025 476 10 = reserved 477 11 = frameTypeEither 478 PP: 00 = singleAddressMode 479 01 = promiscuousMode 480 10 = reserved 481 11 = reserved 482 R: 0 = the training initiator is an end node 483 1 = the training initiator is a repeater 485 The allowed configuration field allows the master mode device to 486 respond with the allowed configuration. The slave mode device sets 487 the contents of this field to all zero bits. The master mode device 488 sets the allowed configuration field as follows: 490 First Octet: Second Octet: 492 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 493 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 494 |v|v|v|D|C|N|r|r| |r|r|r|F|F|P|P|R| 495 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 497 vvv: The version of the 802.12 training protocol with which 498 the training responder is compliant. The current version 499 is 100. 500 D: 0 = No duplicate address has been detected. 501 1 = Duplicate address has been detected 502 C: 0 = The requested configuration is compatible with the 503 network. 504 1 = The requested configuration is not compatible with 505 the network. In this case, the FF, PP, and R bits 506 indicate the configuration that would be allowed. 507 N: 0 = Access will be allowed, providing the configuration 508 is compatible (C = 0). 509 1 = Access is not granted because of security 510 restrictions 511 r: Reserved bits (set to zero) 512 FF: 00 = frameType88023 will be used 513 01 = frameType88025 will be used 514 10 = reserved 515 11 = reserved 516 PP: 00 = singleAddressMode 517 01 = promiscuousMode 518 10 = reserved 519 11 = reserved 520 R: 0 = Requested access as an end node is allowed 521 1 = Requested access as a repeater is allowed 523 Again, note that the most recent version of the IEEE 802.12 standard 524 should be consulted for the most up to date definition of the 525 requested configuration and allowed configuration fields. 527 The data field contains between 594 and 675 octets and is filled in 528 by the training initiator. The first 55 octets may be used for 529 vendor specific protocol information. The remaining octets are all 530 zeros. The length of the training frame combined with the 531 requirement that 24 consecutive training frames be received without 532 error to complete training ensures that marginal links will not 533 complete training. 535 3.9. Mapping of IEEE 802.12 Managed Objects 537 The following table lists all the managed objects defined for 538 oEndNode in the IEEE 802.12 Standard, and the corresponding SNMP 539 objects. 541 IEEE 802.12 Managed Object Corresponding SNMP Object 543 oEndNode 544 .aBroadcastFramesReceived IF-MIB - ifInBroadcastPkts 545 .aBroadcastFramesTransmitted IF-MIB - ifOutBroadcastPkts 546 .aDataErrorFramesReceived dot12InDataErrors 547 .aDesiredFramingType dot12DesiredFramingType 548 .aDesiredPromiscuousStatus dot12DesiredPromiscStatus 549 .aFramesTransmitted IF-MIB - ifOutUCastPkts + 550 ifOutMulticastPkts + 551 ifOutBroadcastPkts 552 .aFramingCapability dot12FramingCapability 553 .aFunctionalAddresses IF-MIB - ifRcvAddressTable 554 .aHighPriorityFramesReceived dot12InHighPriorityFrames 555 .aHighPriorityFramesTransmitted dot12OutHighPriorityFrames 556 .aHighPriorityOctetsReceived dot12InHighPriorityOctets or 557 dot12InHCHighPriorityOctets 558 .aHighPriorityOctetsTransmitted dot12OutHighPriorityOctets or 559 dot12OutHCHighPriorityOctets 560 .aIPMFramesReceived dot12InIPMErrors 561 .aLastTrainingConfig dot12LastTrainingConfig 562 .aMACID IF-MIB - ifIndex 563 .aMACStatus dot12Status 564 .aMACVersion dot12TrainingVersion 565 .aMediaType 566 Tranceiver MIB issue 567 .aMulticastFramesReceived IF-MIB - ifInMulticastPkts 568 .aMulticastFramesTransmitted IF-MIB - ifOutMulticastPkts 569 .aMulticastReceiveStatus IF-MIB - ifRcvAddressTable 570 .aNormalPriorityFramesReceived dot12InNormPriorityFrames 571 .aNormalPriorityOctetsReceived dot12InNormPriorityOctets or 572 dot12InHCNormPriorityOctets 573 .aNullAddressedFramesReceived dot12InNullAddressedFrames 574 .aOctetsTransmitted IF-MIB - ifOutOctets or 575 ifHCOutOctets 576 .aOversizeFramesReceived dot12InOversizeFrameErrors 577 .aReadableFramesReceived IF-MIB - ifInUcastPkts + 578 ifInMulticastPkts + 579 ifInBroadcastPkts 581 .aReadableOctetsReceived IF-MIB - ifInOctets or 582 ifHCInOctets 583 .aReadMulticastList IF-MIB - ifRcvAddressTable 584 .aReadWriteMACAddress IF-MIB - ifPhysAddress 585 .aTransitionsIntoTraining dot12TransitionIntoTrainings 586 .acAddGroupAddress IF-MIB - ifRcvAddressTable 587 .acClose dot12Commands: 'close' 588 .acDeleteGroupAddress IF-MIB - ifRcvAddressTable 589 .acExecuteSelftest IF-MIB - ifAdminStatus 590 .acInitializeMAC dot12Commands: 'reset' 591 .acOpen dot12Commands: 'open' 593 4. Definitions 595 DOT12-IF-MIB DEFINITIONS ::= BEGIN 597 IMPORTS 598 transmission, Counter32, Counter64, OBJECT-TYPE, 599 MODULE-IDENTITY 600 FROM SNMPv2-SMI 601 MODULE-COMPLIANCE, OBJECT-GROUP 602 FROM SNMPv2-CONF 603 ifIndex 604 FROM IF-MIB; 606 dot12MIB MODULE-IDENTITY 607 LAST-UPDATED "9602220452Z" -- February 22, 1996 608 ORGANIZATION "IETF 100VG-AnyLAN MIB Working Group" 609 CONTACT-INFO 610 " John Flick 612 Postal: Hewlett Packard Company 613 8000 Foothills Blvd. M/S 5556 614 Roseville, CA 95747-5556 615 Tel: +1 916 785 4018 616 Fax: +1 916 785 3583 618 E-mail: johnf@hprnd.rose.hp.com" 619 DESCRIPTION 620 "This MIB module describes objects for 621 managing IEEE 802.12 interfaces." 622 ::= { transmission TBD } 624 dot12MIBObjects OBJECT IDENTIFIER ::= { dot12MIB 1 } 626 dot12ConfigTable OBJECT-TYPE 627 SYNTAX SEQUENCE OF Dot12ConfigEntry 628 MAX-ACCESS not-accessible 629 STATUS current 630 DESCRIPTION 631 "Configuration information for a collection of 632 802.12 interfaces attached to a particular 633 system." 634 ::= { dot12MIBObjects 1 } 636 dot12ConfigEntry OBJECT-TYPE 637 SYNTAX Dot12ConfigEntry 638 MAX-ACCESS not-accessible 639 STATUS current 640 DESCRIPTION 641 "Configuration for a particular interface to an 642 802.12 medium." 643 INDEX { ifIndex } 644 ::= { dot12ConfigTable 1 } 646 Dot12ConfigEntry ::= 647 SEQUENCE { 648 dot12CurrentFramingType INTEGER, 649 dot12DesiredFramingType INTEGER, 650 dot12FramingCapability INTEGER, 651 dot12DesiredPromiscStatus INTEGER, 652 dot12TrainingVersion INTEGER, 653 dot12LastTrainingConfig OCTET STRING, 654 dot12Commands INTEGER, 655 dot12Status INTEGER, 656 dot12ControlMode INTEGER 657 } 659 dot12CurrentFramingType OBJECT-TYPE 660 SYNTAX INTEGER { 661 frameType88023(1), 662 frameType88025(2), 663 frameTypeUnknown(3) 664 } 665 MAX-ACCESS read-only 666 STATUS current 667 DESCRIPTION 668 "When dot12DesiredFramingType is one of 669 'frameType88023' or 'frameType88025', this is the 670 type of framing asserted by the interface. 672 When dot12DesiredFramingType is 'frameTypeEither', 673 dot12CurrentFramingType shall be one of 674 'frameType88023' or 'frameType88025' when the 675 dot12Status is 'opened'. When the dot12Status is 676 anything other than 'opened', 677 dot12CurrentFramingType shall take the value of 678 'frameTypeUnknown'." 679 ::= { dot12ConfigEntry 1 } 681 dot12DesiredFramingType OBJECT-TYPE 682 SYNTAX INTEGER { 683 frameType88023(1), 684 frameType88025(2), 685 frameTypeEither(3) 686 } 687 MAX-ACCESS read-write 688 STATUS current 689 DESCRIPTION 690 "The type of framing which will be requested by 691 the interface during the next interface MAC 692 initialization or open action. 694 In master mode, this is the framing mode which 695 will be granted by the interface. Note that 696 for a master mode interface, this object must be 697 equal to 'frameType88023' or 'frameType88025', 698 since a master mode interface cannot grant 699 'frameTypeEither'." 700 REFERENCE 701 "IEEE Standard 802.12-1995, 13.2.5.2.1, 702 aDesiredFramingType." 703 ::= { dot12ConfigEntry 2 } 705 dot12FramingCapability OBJECT-TYPE 706 SYNTAX INTEGER { 707 frameType88023(1), 708 frameType88025(2), 709 frameTypeEither(3) 710 } 711 MAX-ACCESS read-only 712 STATUS current 713 DESCRIPTION 714 "The type of framing this interface is capable of 715 supporting." 716 REFERENCE 717 "IEEE Standard 802.12-1995, 13.2.5.2.1, 718 aFramingCapability." 719 ::= { dot12ConfigEntry 3 } 721 dot12DesiredPromiscStatus OBJECT-TYPE 722 SYNTAX INTEGER { 723 singleAddressMode(1), 724 promiscuousMode(2) 725 } 726 MAX-ACCESS read-write 727 STATUS current 728 DESCRIPTION 729 "This object is used to select the promiscuous 730 mode that this interface will request in the next 731 training packet issued on this interface. 732 Whether the repeater grants the requested mode 733 must be verified by examining the state of the PP 734 bits in the corresponding instance of 735 dot12LastTrainingConfig. 737 In master mode, this object controls whether or 738 not promiscuous mode will be granted by the 739 interface when requested by the lower level 740 device. 742 Note that this object indicates the desired mode 743 for the next time the interface trains. The 744 currently active mode will be reflected in 745 dot12LastTrainingConfig and in ifPromiscuousMode." 746 REFERENCE 747 "IEEE Standard 802.12-1995, 13.2.5.2.1, 748 aDesiredPromiscuousStatus." 749 ::= { dot12ConfigEntry 4 } 751 dot12TrainingVersion OBJECT-TYPE 752 SYNTAX INTEGER (0..7) 753 MAX-ACCESS read-only 754 STATUS current 755 DESCRIPTION 756 "The value that will be used in the version bits 757 (vvv bits) in training frames on this interface. 758 This is the highest version number supported by 759 this MAC." 760 REFERENCE 761 "IEEE Standard 802.12-1995, 13.2.5.2.1, 762 aMACVersion." 763 ::= { dot12ConfigEntry 5 } 765 dot12LastTrainingConfig OBJECT-TYPE 766 SYNTAX OCTET STRING (SIZE(2)) 767 MAX-ACCESS read-only 768 STATUS current 769 DESCRIPTION 770 "This 16 bit field contains the configuration 771 bits from the most recent error-free training 772 frame received during training on this interface. 773 Training request frames are received when in 774 master mode, while training response frames are 775 received in slave mode. On master mode interfaces, 776 this object contains the contents of the 777 requested configuration field of the most recent 778 training request frame. On slave mode interfaces, 779 this object contains the contents of the allowed 780 configuration field of the most recent training 781 response frame. The format of the current version 782 of this field is described in section 3.8. Please 783 refer to the most recent version of the IEEE 784 802.12 standard for the most up-to-date definition 785 of the format of this object." 786 REFERENCE 787 "IEEE Standard 802.12-1995, 13.2.5.2.1, 788 aLastTrainingConfig." 789 ::= { dot12ConfigEntry 6 } 791 dot12Commands OBJECT-TYPE 792 SYNTAX INTEGER { 793 noOp(1), 794 open(2), 795 reset(3), 796 close(4) 797 } 798 MAX-ACCESS read-write 799 STATUS current 800 DESCRIPTION 801 "If the current value of dot12Status is 'closed', 802 setting the value of this object to 'open' will 803 change the corresponding instance of MIB-II's 804 ifAdminStatus to 'up', cause this interface to 805 enter the 'opening' state, and will cause training 806 to be initiated on this interface. The progress 807 and success of the open is given by the values of 808 the dot12Status object. Setting this object to 809 'open' when dot12Status has a value other than 810 'closed' has no effect. 812 Setting the corresponding instance of ifAdminStatus 813 to 'up' when the current value of dot12Status is 814 'closed' will have the same effect as setting this 815 object to 'open'. Setting ifAdminStatus to 'up' 816 when dot12Status has a value other than 'closed' 817 has no effect. 819 Setting the value of this object to 'close' will 820 move this interface into the 'closed' state and 821 cause all transmit and receive actions to stop. 822 This object will then have to be set to 'open' in 823 order to reinitiate training. 825 Setting the corresponding instance of ifAdminStatus 826 to 'down' will have the same effect as setting this 827 object to 'close'. 829 Setting the value of this object to 'reset' when 830 the current value of dot12Status has a value other 831 than 'closed' will reset the interface. On a 832 reset, all MIB counters should retain their values. 834 This will cause the MAC to initiate an 835 acInitializeMAC action as specified in IEEE 802.12. 836 This will cause training to be reinitiated on this 837 interface. Setting this object to 'reset' when 838 dot12Status has a value of 'closed' has no effect. 839 Setting this object to 'reset' has no effect on the 840 corresponding instance of ifAdminStatus. 842 Setting the value of this object to 'noOp' has no 843 effect. 845 When read, this object will always have a value 846 of 'noOp'." 847 REFERENCE 848 "IEEE Standard 802.12-1995, 13.2.5.2.2, 849 acOpen, acClose, acInitializeMAC. 850 Also, RFC1231 IEEE802.5 Token Ring MIB, 851 dot5Commands." 852 ::= { dot12ConfigEntry 7 } 854 dot12Status OBJECT-TYPE 855 SYNTAX INTEGER { 856 opened(1), 857 closed(2), 858 opening(3), 859 openFailure(5), 860 linkFailure(6) 861 } 862 MAX-ACCESS read-only 863 STATUS current 864 DESCRIPTION 865 "The current interface status with respect to 866 training. One of the following values: 868 opened - Training has completed 869 successfully. 870 closed - MAC has been disabled by 871 setting dot12Commands to 872 'close'. 873 opening - MAC is in training. Training 874 signals have been received. 875 openFailure - Passed 24 error-free packets, 876 but there is a problem, noted 877 in the training configuration 878 bits (dot12LastTrainingConfig). 879 linkFailure - Training signals not received, 880 or could not pass 24 error-free 881 packets. 883 Whenever the dot12Commands object is set to 884 'close' or ifAdminStatus is set to 'down', the MAC 885 will go silent, dot12Status will be 'closed', and 886 ifOperStatus will be 'down'. 888 When the value of this object is equal to 'closed' 889 and the dot12Commands object is set to 'open' or 890 the ifAdminStatus object is set to 'up', training 891 will be initiated on this interface. When the 892 value of this object is not equal to 'closed' and 893 the dot12Commands object is set to 'reset', 894 training will be reinitiated on this interface. 895 Note that sets of some other objects (e.g. 896 dot12ControlMode) or external events (e.g. MAC 897 protocol violations) may also cause training to be 898 reinitiated on this interface. 900 When training is initiated or reinitiated on an 901 interface, the end node will send Training_Up to 902 the master and initially go to the 'linkFailure' 903 state and ifOperStatus will go to 'down'. 904 When the master sends back Training_Down, 905 dot12Status will change to the 'opening' state, 906 and training packets will be transferred. 908 After all of the training packets have been 909 passed, dot12Status will change to 'linkFailure' 910 if 24 consecutive error-free packets were not 911 passed, 'opened' if 24 consecutive error-free 912 packets were passed and the training 913 configuration bits were OK, or 'openFailure' if 914 there were 24 consecutive error-free packets, but 915 there was a problem with the training 916 configuration bits. 918 When in the 'openFailure' state, the 919 dot12LastTrainingConfig object will contain the 920 configuration bits from the last training 921 packet which can be examined to determine the 922 exact reason for the training configuration 923 failure. 925 If training did not succeed (dot12Status is 926 'linkFailure' or 'openFailure), the entire 927 process will be restarted after 928 MAC_Retraining_Delay_Timer seconds. 930 If training does succeed (dot12Status changes to 931 'opened'), ifOperStatus will change to 'up'. If 932 training does not succeed (dot12Status changes to 933 'linkFailure' or 'openFailure'), ifOperStatus will 934 remain 'down'." 935 REFERENCE 936 "IEEE Standard 802.12-1995, 13.2.5.2.1, 937 aMACStatus." 938 ::= { dot12ConfigEntry 8 } 940 dot12ControlMode OBJECT-TYPE 941 SYNTAX INTEGER { 942 masterMode(1), 943 slaveMode(2), 944 learn(3) 945 } 946 MAX-ACCESS read-write 947 STATUS current 948 DESCRIPTION 949 "This object is used to configure and report 950 whether or not this interface is operating in 951 master mode. In a Demand Priority network, end 952 node interfaces typically operate in slave mode, 953 while switch interfaces may control the Demand 954 Priority protocol and operate in master mode. 956 This object may be implemented as a read-only 957 object by those agents and interfaces that do not 958 implement software control of master mode. In 959 particular, interfaces that cannot operate in 960 master mode, and interfaces on which master mode 961 is controlled by a pushbutton on the device, 962 should implement this object read-only. 964 Some interfaces do not require network management 965 configuration of this feature and can autosense 966 whether to use master mode or slave mode. The 967 value 'learn' is used for that purpose. While 968 autosense is taking place, the value 'learn' is 969 returned. 971 A network management operation which modifies the 972 value of dot12ControlMode causes the interface 973 to retrain." 974 ::= { dot12ConfigEntry 9 } 976 dot12StatTable OBJECT-TYPE 977 SYNTAX SEQUENCE OF Dot12StatEntry 978 MAX-ACCESS not-accessible 979 STATUS current 980 DESCRIPTION 981 "Statistics for a collection of 802.12 interfaces 982 attached to a particular system." 983 ::= { dot12MIBObjects 2 } 985 dot12StatEntry OBJECT-TYPE 986 SYNTAX Dot12StatEntry 987 MAX-ACCESS not-accessible 988 STATUS current 989 DESCRIPTION 990 "Statistics for a particular interface to an 991 802.12 medium. The receive statistics in this 992 table apply only to packets received by this 993 station (i.e., packets whose destination address 994 is either the local station address, the 995 broadcast address, or a multicast address that 996 this station is receiving, unless the station is 997 in promiscuous mode)." 998 INDEX { ifIndex } 999 ::= { dot12StatTable 1 } 1001 Dot12StatEntry ::= 1002 SEQUENCE { 1003 dot12InHighPriorityFrames Counter32, 1004 dot12InHighPriorityOctets Counter32, 1005 dot12InNormPriorityFrames Counter32, 1006 dot12InNormPriorityOctets Counter32, 1007 dot12InIPMErrors Counter32, 1008 dot12InOversizeFrameErrors Counter32, 1009 dot12InDataErrors Counter32, 1010 dot12InNullAddressedFrames Counter32, 1011 dot12OutHighPriorityFrames Counter32, 1012 dot12OutHighPriorityOctets Counter32, 1013 dot12TransitionIntoTrainings Counter32, 1014 dot12HCInHighPriorityOctets Counter64, 1015 dot12HCInNormPriorityOctets Counter64, 1016 dot12HCOutHighPriorityOctets Counter64 1017 } 1019 dot12InHighPriorityFrames OBJECT-TYPE 1020 SYNTAX Counter32 1021 MAX-ACCESS read-only 1022 STATUS current 1023 DESCRIPTION 1024 "This object is a count of high priority frames 1025 that have been received on this interface. 1026 Includes both good and bad high priority frames, 1027 as well as high priority training frames. Does 1028 not include normal priority frames which were 1029 priority promoted." 1030 REFERENCE 1031 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1032 aHighPriorityFramesReceived." 1033 ::= { dot12StatEntry 1 } 1035 dot12InHighPriorityOctets OBJECT-TYPE 1036 SYNTAX Counter32 1037 MAX-ACCESS read-only 1038 STATUS current 1039 DESCRIPTION 1040 "This object is a count of the number of octets 1041 contained in high priority frames that have been 1042 received on this interface. This counter is 1043 incremented by OctetCount for each frame received 1044 on this interface which is counted by 1045 dot12InHighPriorityFrames. 1047 Note that this counter will roll over very 1048 quickly. It is provided for backward 1049 compatibility for Network Management protocols 1050 that do not support 64 bit counters (e.g. SNMP 1051 version 1)." 1052 REFERENCE 1053 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1054 aHighPriorityOctetsReceived." 1055 ::= { dot12StatEntry 2 } 1057 dot12InNormPriorityFrames OBJECT-TYPE 1058 SYNTAX Counter32 1059 MAX-ACCESS read-only 1060 STATUS current 1061 DESCRIPTION 1062 "This object is a count of normal priority frames 1063 that have been received on this interface. 1064 Includes both good and bad normal priority 1065 frames, as well as normal priority training 1066 frames and normal priority frames which were 1067 priority promoted." 1068 REFERENCE 1069 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1070 aNormalPriorityFramesReceived." 1071 ::= { dot12StatEntry 3 } 1073 dot12InNormPriorityOctets OBJECT-TYPE 1074 SYNTAX Counter32 1075 MAX-ACCESS read-only 1076 STATUS current 1077 DESCRIPTION 1078 "This object is a count of the number of octets 1079 contained in normal priority frames that have 1080 been received on this interface. This counter is 1081 incremented by OctetCount for each frame received 1082 on this interface which is counted by 1083 dot12InNormPriorityFrames. 1085 Note that this counter will roll over very 1086 quickly. It is provided for backward 1087 compatibility for Network Management protocols 1088 that do not support 64 bit counters (e.g. SNMP 1089 version 1)." 1090 REFERENCE 1091 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1092 aNormalPriorityOctetsReceived." 1093 ::= { dot12StatEntry 4 } 1095 dot12InIPMErrors OBJECT-TYPE 1096 SYNTAX Counter32 1097 MAX-ACCESS read-only 1098 STATUS current 1099 DESCRIPTION 1100 "This object is a count of the number of frames 1101 that have been received on this interface with an 1102 invalid packet marker and no PMI errors. A 1103 repeater will write an invalid packet marker to 1104 the end of a frame containing errors as it is 1105 forwarded through the repeater to the other 1106 ports. This counter is incremented by one for 1107 each frame received on this interface which has 1108 had an invalid packet marker added to the end of 1109 the frame." 1110 REFERENCE 1111 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1112 aIPMFramesReceived." 1113 ::= { dot12StatEntry 5 } 1115 dot12InOversizeFrameErrors OBJECT-TYPE 1116 SYNTAX Counter32 1117 MAX-ACCESS read-only 1118 STATUS current 1119 DESCRIPTION 1120 "This object is a count of oversize frames 1121 received on this interface. This counter is 1122 incremented by one for each frame received on 1123 this interface whose OctetCount is larger than 1124 the maximum legal frame size. The frame size 1125 which causes this counter to increment is 1126 dependent on the current framing type." 1127 REFERENCE 1128 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1129 aOversizeFramesReceived." 1130 ::= { dot12StatEntry 6 } 1132 dot12InDataErrors OBJECT-TYPE 1133 SYNTAX Counter32 1134 MAX-ACCESS read-only 1135 STATUS current 1136 DESCRIPTION 1137 "This object is a count of errored frames 1138 received on this interface. This counter is 1139 incremented by one for each frame received on 1140 this interface with any of the following errors: 1141 bad FCS (with no IPM), PMI errors (excluding 1142 frames with an IPM as the only PMI error), 1143 undersize, bad start of frame delimiter, or bad 1144 end of packet marker. Does not include frames 1145 counted by dot12InIPMErrors, 1146 dot12InNullAddressedFrames, or 1147 dot12InOversizeFrameErrors. 1149 This counter indicates problems with the cable 1150 directly attached to this interface, while 1151 dot12InIPMErrors indicates problems with remote 1152 cables." 1153 REFERENCE 1154 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1155 aDataErrorFramesReceived." 1156 ::= { dot12StatEntry 7 } 1158 dot12InNullAddressedFrames OBJECT-TYPE 1159 SYNTAX Counter32 1160 MAX-ACCESS read-only 1161 STATUS current 1162 DESCRIPTION 1163 "This object is a count of null addressed frames 1164 received on this interface. This counter is 1165 incremented by one for each frame received on 1166 this interface with a destination MAC address 1167 consisting of all zero bits. Both void and 1168 training frames are included in this counter. 1170 Note that since this station would normally not 1171 receive null addressed frames, this counter is 1172 only incremented when this station is operating 1173 in promiscuous mode or in training." 1174 REFERENCE 1175 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1176 aNullAddressedFramesReceived." 1177 ::= { dot12StatEntry 8 } 1179 dot12OutHighPriorityFrames OBJECT-TYPE 1180 SYNTAX Counter32 1181 MAX-ACCESS read-only 1182 STATUS current 1183 DESCRIPTION 1184 "This counter is incremented by one for each high 1185 priority frame successfully transmitted out this 1186 interface." 1187 REFERENCE 1188 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1189 aHighPriorityFramesTransmitted." 1190 ::= { dot12StatEntry 9 } 1192 dot12OutHighPriorityOctets OBJECT-TYPE 1193 SYNTAX Counter32 1194 MAX-ACCESS read-only 1195 STATUS current 1196 DESCRIPTION 1197 "This counter is incremented by OctetCount for 1198 each frame counted by dot12OutHighPriorityFrames. 1200 Note that this counter will roll over very 1201 quickly. It is provided for backward 1202 compatibility for Network Management protocols 1203 that do not support 64 bit counters (e.g. SNMP 1204 version 1)." 1205 REFERENCE 1206 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1207 aHighPriorityOctetsTransmitted." 1208 ::= { dot12StatEntry 10 } 1210 dot12TransitionIntoTrainings OBJECT-TYPE 1211 SYNTAX Counter32 1212 MAX-ACCESS read-only 1213 STATUS current 1214 DESCRIPTION 1215 "This object is a count of the number of times 1216 this interface has entered the training state. 1217 This counter is incremented by one each time 1218 dot12Status transitions to 'linkFailure' from any 1219 state other than 'opening' or 'openFailure'." 1220 REFERENCE 1221 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1222 aTransitionsIntoTraining." 1223 ::= { dot12StatEntry 11 } 1225 dot12HCInHighPriorityOctets OBJECT-TYPE 1226 SYNTAX Counter64 1227 MAX-ACCESS read-only 1228 STATUS current 1229 DESCRIPTION 1230 "This object is a count of the number of octets 1231 contained in high priority frames that have been 1232 received on this interface. This counter is 1233 incremented by OctetCount for each frame received 1234 on this interface which is counted by 1235 dot12InHighPriorityFrames. 1237 This counter is a 64 bit version of 1238 dot12InHighPriorityOctets. It should be used by 1239 Network Management protocols which support 64 bit 1240 counters (e.g. SNMPv2)." 1241 REFERENCE 1242 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1243 aHighPriorityOctetsReceived." 1244 ::= { dot12StatEntry 12 } 1246 dot12HCInNormPriorityOctets OBJECT-TYPE 1247 SYNTAX Counter64 1248 MAX-ACCESS read-only 1249 STATUS current 1250 DESCRIPTION 1251 "This object is a count of the number of octets 1252 contained in normal priority frames that have 1253 been received on this interface. This counter is 1254 incremented by OctetCount for each frame received 1255 on this interface which is counted by 1256 dot12InNormPriorityFrames. 1258 This counter is a 64 bit version of 1259 dot12InNormPriorityOctets. It should be used by 1260 Network Management protocols which support 64 bit 1261 counters (e.g. SNMPv2)." 1262 REFERENCE 1263 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1264 aNormalPriorityOctetsReceived." 1265 ::= { dot12StatEntry 13 } 1267 dot12HCOutHighPriorityOctets OBJECT-TYPE 1268 SYNTAX Counter64 1269 MAX-ACCESS read-only 1270 STATUS current 1271 DESCRIPTION 1272 "This counter is incremented by OctetCount for 1273 each frame counted by dot12OutHighPriorityFrames. 1275 This counter is a 64 bit version of 1276 dot12OutHighPriorityOctets. It should be used by 1277 Network Management protocols which support 64 bit 1278 counters (e.g. SNMPv2)." 1279 REFERENCE 1280 "IEEE Standard 802.12-1995, 13.2.5.2.1, 1281 aHighPriorityOctetsTransmitted." 1282 ::= { dot12StatEntry 14 } 1284 -- conformance information 1286 dot12Conformance OBJECT IDENTIFIER ::= { dot12MIB 2 } 1288 dot12Compliances OBJECT IDENTIFIER ::= { dot12Conformance 1 } 1289 dot12Groups OBJECT IDENTIFIER ::= { dot12Conformance 2 } 1291 -- compliance statements 1293 dot12Compliance MODULE-COMPLIANCE 1294 STATUS current 1295 DESCRIPTION 1296 "The compliance statement for managed network 1297 entities that have 802.12 interfaces." 1299 MODULE -- this module 1300 MANDATORY-GROUPS { dot12ConfigGroup, dot12StatsGroup } 1302 OBJECT dot12DesiredFramingType 1303 MIN-ACCESS read-only 1304 DESCRIPTION 1305 "Write access to this object is not required." 1307 OBJECT dot12DesiredPromiscStatus 1308 MIN-ACCESS read-only 1309 DESCRIPTION 1310 "Write access to this object is not required." 1312 OBJECT dot12Commands 1313 MIN-ACCESS read-only 1314 DESCRIPTION 1315 "Write access to this object is not required." 1317 OBJECT dot12ControlMode 1318 MIN-ACCESS read-only 1319 DESCRIPTION 1320 "Write access to this object is not required." 1321 ::= { dot12Compliances 1 } 1323 -- units of conformance 1325 dot12ConfigGroup OBJECT-GROUP 1326 OBJECTS { dot12DesiredFramingType, 1327 dot12FramingCapability, 1328 dot12DesiredPromiscStatus, 1329 dot12TrainingVersion, 1330 dot12LastTrainingConfig, 1331 dot12Commands, dot12Status, 1332 dot12CurrentFramingType, 1333 dot12ControlMode } 1334 STATUS current 1335 DESCRIPTION 1336 "A collection of objects for managing the status 1337 and configuration of IEEE 802.12 interfaces." 1338 ::= { dot12Groups 1 } 1340 dot12StatsGroup OBJECT-GROUP 1341 OBJECTS { dot12InHighPriorityFrames, 1342 dot12InHighPriorityOctets, 1343 dot12InNormPriorityFrames, 1344 dot12InNormPriorityOctets, 1345 dot12InIPMErrors, 1346 dot12InOversizeFrameErrors, 1347 dot12InDataErrors, 1348 dot12InNullAddressedFrames, 1349 dot12OutHighPriorityFrames, 1350 dot12OutHighPriorityOctets, 1351 dot12TransitionIntoTrainings, 1352 dot12HCInHighPriorityOctets, 1353 dot12HCInNormPriorityOctets, 1354 dot12HCOutHighPriorityOctets } 1355 STATUS current 1356 DESCRIPTION 1357 "A collection of objects providing statistics for 1358 IEEE 802.12 interfaces." 1359 ::= { dot12Groups 2 } 1361 END 1363 5. Acknowledgements 1365 This document was produced by the IETF 100VG-AnyLAN Working Group. 1366 It is based on the work of IEEE 802.12. 1368 6. References 1370 [1] Information processing systems - Open Systems Interconnection - 1371 Specification of Abstract Syntax Notation One (ASN.1), 1372 International Organization for Standardization. International 1373 Standard 8824 (December, 1987). 1375 [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1376 S. Waldbusser, "Structure of Management Information for Version 1377 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 1378 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach 1379 Consulting, Inc., International Network Services, January 1996. 1381 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1382 S. Waldbusser, "Textual Conventions for Version 2 of the Simple 1383 Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, 1384 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1385 International Network Services, January 1996. 1387 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1388 S. Waldbusser, "Conformance Statements for Version 2 of the 1389 Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP 1390 Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 1391 Inc., International Network Services, January 1996. 1393 [5] McCloghrie, K., and M. Rose, "Management Information Base for 1394 Network Management of TCP/IP-based internets - MIB-II", STD 17, 1395 RFC 1213, Hughes LAN Systems, Performance Systems International, 1396 March 1991. 1398 [6] IEEE, "Demand Priority Access Method, Physical Layer and 1399 Repeater Specifications for 100 Mb/s Operation", IEEE Standard 1400 802.12-1995" 1402 [7] McCloghrie, K., and Kastenholz, F., "Evolution of the Interfaces 1403 Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, 1404 January 1994. 1406 [8] Kastenholz, F., "Definitions of Managed Objects for the 1407 Ethernet-like Interface Types", STD 50, RFC 1643, FTP Software, 1408 Inc., July, 1994. 1410 [9] Kastenholz, F., "Definitions of Managed Objects for the 1411 Ethernet-like Interface Types using SMIv2", RFC 1650, FTP 1412 Software, Inc., August, 1994. 1414 [10] McCloghrie, K., and Decker, E., "IEEE 802.5 MIB using SMIv2", 1415 RFC 1748, Cisco Systems, Inc., December, 1994. 1417 [11] McCloghrie, K., Baker, F., and Decker, E., "IEEE 802.5 Station 1418 Source Routing MIB using SMIv2", RFC 1749, Cisco Systems, Inc., 1419 December, 1994. 1421 7. Security Considerations 1423 Security issues are not discussed in this memo. 1425 8. Author's Address 1427 John Flick 1428 Hewlett Packard Company 1429 8000 Foothills Blvd. M/S 5556 1430 Roseville, CA 95747-5556 1432 Phone: +1 916 785 4018 1433 Email: johnf@hprnd.rose.hp.com 1435 Table of Contents 1437 1. Introduction ............................................... 2 1438 2. Object Definitions ......................................... 2 1439 3. Overview ................................................... 2 1440 3.1. MAC Addresses ............................................ 3 1441 3.2. Relation to RFC 1213 ..................................... 3 1442 3.3. Relation to RFC 1573 ..................................... 3 1443 3.3.1. Layering Model ......................................... 4 1444 3.3.2. Virtual Circuits ....................................... 4 1445 3.3.3. ifTestTable ............................................ 4 1446 3.3.4. ifRcvAddressTable ...................................... 4 1447 3.3.5. ifPhysAddress .......................................... 4 1448 3.3.6. Specific Interface MIB Objects ......................... 5 1449 3.4. Relation to RFC 1643, RFC 1650, and RFC 1748 ............. 8 1450 3.5. Relation to RFC 1749 ..................................... 8 1451 3.6. Master Mode Operation .................................... 9 1452 3.7. Normal and High Priority Counters ........................ 9 1453 3.8. IEEE 802.12 Training Frames .............................. 10 1454 3.9. Mapping of IEEE 802.12 Managed Objects ................... 13 1455 4. Definitions ................................................ 15 1456 5. Acknowledgements ........................................... 31 1457 6. References ................................................. 31 1458 7. Security Considerations .................................... 32 1459 8. Author's Address ........................................... 32