idnits 2.17.1 draft-ietf-vgmib-interfaces-mib-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) 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 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 6 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 (November 10, 1995) is 10393 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 1280, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1286, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1442 (ref. '2') (Obsoleted by RFC 1902) ** Obsolete normative reference: RFC 1443 (ref. '3') (Obsoleted by RFC 1903) ** Obsolete normative reference: RFC 1444 (ref. '4') (Obsoleted by RFC 1904) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1573 (ref. '7') (Obsoleted by RFC 2233) ** Downref: Normative reference to an Historic RFC: RFC 1749 (ref. '8') Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft IEEE 802.12 Interface MIB November 10 1995 3 Definitions of Managed Objects for IEEE 802.12 Interfaces 5 November 10, 1995 7 John Flick 9 Hewlett Packard Company 10 8000 Foothills Blvd. M/S 5556 11 Roseville, CA 95747-5556 13 johnf@hprnd.rose.hp.com 15 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 1. Abstract 37 This memo defines an experimental portion of the Management 38 Information Base (MIB) for use with network management protocols in 39 TCP/IP-based internets. In particular, it defines objects for 40 managing network interfaces based on IEEE 802.12. 42 2. Object Definitions 44 Management information is viewed as a collection of managed objects, 45 residing in a virtual information store, termed the Management 46 Information Base (MIB). Collections of related objects are defined 47 in MIB modules. MIB modules are written using a subset of Abstract 48 Syntax Notation One (ASN.1) [1] termed the Structure of Management 49 Information (SMI) [2]. In particular, each object type is named by 50 an OBJECT IDENTIFIER, an administratively assigned name. The object 51 type together with an object instance serves to uniquely identify a 52 specific instantiation of the object. For human convenience, we 53 often use a textual string, termed the descriptor, to refer to the 54 object type. 56 3. Overview 58 Instances of these object types represent attributes of an interface 59 to a 100VG-AnyLAN communications medium. At present, 100VG-AnyLAN 60 media are identified by one value of the ifType object in the 61 Internet-standard MIB: 63 ieee80212(55) 65 For this interface, the value of the ifSpecific variable in the MIB- 66 II [5] has the OBJECT IDENTIFIER value: 68 dot12MIB OBJECT IDENTIFIER ::= { experimental 63 } 70 The definitions presented here are based on the IEEE Standard 802.12, 71 [6] Clause 13 "Layer Management Functions And Services", and Annex E 72 "GDMO Specifications for Demand Priority Managed Objects". 73 Implementors of these MIB objects should note that the IEEE document 74 explicitly describes (in the form of Pascal pseudocode) when, where, 75 and how various MAC attributes are measured. The IEEE document also 76 describes the effects of MAC actions that may be invoked by 77 manipulating instances of the MIB objects defined here. 79 To the extent that some of the attributes defined in [6] are 80 represented by previously defined objects in the Internet-standard 81 MIB [5] or in the Evolution of the Interfaces Group of MIB-II [7], 82 such attributes are not redundantly represented by objects defined in 83 this memo. Among the attributes represented by objects defined in 84 other memos are the number of octets transmitted or received on a 85 particular interface, the MAC address of an interface, and multicast 86 information associated with an interface. 88 3.1. MAC Addresses 90 All representations of MAC addresses in this MIB module, and in other 91 related MIB modules (like RFC 1573), are in "canonical" order defined 92 by 802.1a, i.e., as if it were transmitted least significant bit 93 first. This is true even if the interface is operating in token ring 94 framing mode, which requires MAC addresses to be transmitted most 95 significant bit first. 97 3.2. Relation to RFC 1213 99 This section applies only when this MIB is used in conjunction with 100 the "old" (i.e., pre-RFC 1573) interface group. 102 The relationship between a 100VG-AnyLAN interface and an interface in 103 the context of the Internet-standard MIB is one-to-one. As such, the 104 value of an ifIndex object instance can be directly used to identify 105 corresponding instances of the objects defined herein. 107 3.3. Relation to RFC 1573 109 RFC 1573, the Interface MIB Evolution, requires that any MIB which is 110 an adjunct of the Interface MIB, clarify specific areas within the 111 Interface MIB. These areas are intentionally left vague in RFC 1573 112 to avoid over constraining the MIB, thereby precluding management of 113 certain media-types. 115 An agent which implements this MIB module must support the 116 ifGeneralGroup, ifStackGroup, ifHCPacketGroup, and ifRcvAddressGroup 117 of RFC 1573. 119 Section 3.3 of RFC 1573 enumerates several areas which a media- 120 specific MIB must clarify. In addition, there are some objects in 121 RFC 1573 for which additional clarification of how to apply them to a 122 100VG-AnyLAN interface would be helpful. Each of these areas is 123 addressed in a following subsection. The implementor is referred to 124 RFC 1573 in order to understand the general intent of these areas. 126 3.3.1. Layering Model 128 For the typical usage of this MIB module, there will be no sub-layers 129 "above" or "below" the 802.12 Interface. However, this MIB module 130 does not preclude such layering. 132 3.3.2. Virtual Circuits 134 This medium does not support virtual circuits and this area is not 135 applicable to this MIB. 137 3.3.3. ifTestTable 139 This MIB does not define any tests for media instrumented by this 140 MIB. Implementation of the ifTestTable is not required. An 141 implementation may optionally implement the ifTestTable to execute 142 vendor specific tests. 144 3.3.4. ifRcvAddressTable 146 This table contains all IEEE addresses, unicast, multicast, and 147 broadcast, for which this interface will receive packets and forward 148 them up to a higher layer entity for consumption. In addition, when 149 the interface is using 802.5 framing mode, the ifRcvAddressTable will 150 contain the functional address mask. 152 In the event that the interface is part of a MAC bridge, this table 153 does not include unicast addresses which are accepted for possible 154 forwarding out some other port. This table is explicitly not 155 intended to provide a bridge address filtering mechanism. 157 3.3.5. ifPhysAddress 159 This object contains the IEEE 802.12 address which is placed in the 160 source-address field of any frames that originate at this interface. 161 Usually this will be kept in ROM on the interface hardware. Some 162 systems may set this address via software. 164 In a system where there are several such addresses the designer has a 165 tougher choice. The address chosen should be the one most likely to 166 be of use to network management (e.g. the address placed in ARP 167 responses for systems which are primarily IP systems). 169 If the designer truly can not choose, use of the factory-provided ROM 170 address is suggested. 172 If the address can not be determined, an octet string of zero length 173 should be returned. 175 The address is stored in binary in this object. The address is 176 stored in "canonical" bit order, that is, the Group Bit is positioned 177 as the low-order bit of the first octet. Thus, the first byte of a 178 multicast address would have the bit 0x01 set. This is true even 179 when the interface is using token ring framing mode, which transmits 180 addresses high-order bit first. 182 3.3.6. Specific Interface MIB Objects 184 The following table provides specific implementation guidelines for 185 the interface group objects in the conformance groups listed above. 187 Object Use for an 802.12 Interface 189 ifIndex Each 802.12 interface is represented by an 190 ifEntry. Interface tables in this MIB 191 module are indexed by ifIndex. 193 ifDescr Interface description. 195 ifType The IANA reserved value for 802.12 - 55. 197 ifMtu The value of ifMtu on an 802.12 interface 198 will depend on the type of framing that is 199 in use on that interface. Changing the 200 dot12DesiredFramingType may have the effect 201 of changing ifMtu after the next time that 202 the interface trains. When 203 dot12CurrentFramingType is equal to 204 frameType88023, ifMtu will be equal to 205 1500. When dot12CurrentFramingType is 206 equal to frameType88025, ifMtu will be 207 4464. 209 ifSpeed The speed of the interface in bits per 210 second. For current 802.12 211 implementations, this will be equal to 212 100,000,000 (100 million). 214 ifPhysAddress See Section 3.3.5. 216 ifAdminStatus Write access is not required. Support for 217 'testing' is not required. Setting this 218 object to 'up' will cause dot12Commands to 219 be set to 'open'. Setting this object to 220 'down' will cause dot12Commands to be set 221 to 'close'. Setting dot12Commands to 222 'open' will set this object to 'up'. 223 Setting dot12Commands to 'close' will set 224 this object to 'down'. Setting 225 dot12Commands to 'reset' will have no 226 effect on this object. 228 ifOperStatus When dot12Status is equal to 'opened', this 229 object will be equal to 'up'. When 230 dot12Status is equal to 'closed', 'opening', 231 'openFailure' or 'linkFailure', this object 232 will be equal to 'down'. Support for 233 'testing' is not required, but may be used 234 to indicate that a vendor specific test is 235 in progress. The value 'dormant' has no 236 meaning for an IEEE 802.12 interface. 238 ifLastChange Refer to [7]. 240 ifInOctets The number of octets in valid MAC frames 241 received on this interface, including the 242 MAC header and FCS. 244 ifInUcastPkts Refer to [7]. 246 ifInDiscards Refer to [7]. 248 ifInErrors The sum for this interface of 249 dot12InIPMErrors, 250 dot12InOversizeFrameErrors, 251 dot12InDataErrors, and any additional 252 internal errors that may occur in an 253 implementation. 255 ifInUnknownProtos Refer to [7]. 257 ifOutOctets The number of octets transmitted in MAC 258 frames on this interface, including the MAC 259 header and FCS. 261 ifOutUcastPkts Refer to [7]. 263 ifOutDiscards Refer to [7]. 265 ifOutErrors The number of implementation-specific 266 internal transmit errors on this interface. 268 ifName Locally-significant textual name for the 269 interface (e.g. vg0). 271 ifInMulticastPkts Refer to [7]. When dot12CurrentFramingType 272 is frameType88025, this count includes 273 packets addressed to functional addresses. 275 ifInBroadcastPkts Refer to [7]. 277 ifOutMulticastPkts Refer to [7]. When dot12CurrentFramingType 278 is frameType88025, this count includes 279 packets addressed to functional addresses. 281 ifOutBroadcastPkts Refer to [7]. 283 ifHCInOctets 64-bit version of ifInOctets. 285 ifHCOutOctets 64-bit version of ifOutOctets 287 ifHC*Pkts Not required for 100 MBit interfaces. 288 Future IEEE 802.12 interfaces which operate 289 at higher speeds may require implemenation 290 of these counters, but such interfaces are 291 beyond the scope of this memo. 293 ifLinkUpDownTrapEnable Refer to [7]. Default is 'enabled'. 295 ifHighSpeed The speed of the interface in millions of 296 bits per second. For current 802.12 297 implementations, this will be equal to 100. 299 ifPromiscuousMode Reflects whether the interface has 300 successfully trained and is currently 301 operating in promiscuous mode. 302 dot12DesiredPromiscStatus is used to select 303 the promiscuous mode to be requested in the 304 next training attempt. Setting 305 ifPromiscuousMode will update 306 dot12DesiredPromiscStatus and cause the 307 interface to attempt to retrain using the 308 new promiscuous mode. After the interface 309 has retrained, ifPromiscuousMode will 310 reflect the mode that is in use, not the 311 mode that was requested. 313 ifConnectorPresent This will normally be 'true'. 315 ifStackHigherLayer Refer to section 3.3.1 316 ifStackLowerLayer 317 ifStackStatus 319 ifRcvAddressAddress Refer to section 3.3.4. 320 ifRcvAddressStatus 321 ifRcvAddressType 323 3.4. Relation to RFC 1749 325 When an IEEE 802.12 interface is operating in token ring framing 326 mode, and the end node supports token ring source routing, the agent 327 should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB 328 [8] for those interfaces. 330 3.5. Master Mode Operation 332 In a 100VG-AnyLAN network, "master" devices act as network 333 controllers to decide when to grant requesting end-nodes permission 334 to transmit. These master devices may be repeaters, or other active 335 controller devices such as switches. 337 Devices which do not act as network controllers, such as end-nodes or 338 passive switches, are considered to be operating in "slave" mode. 340 The dot12ControlMode object indicates if the interface is operating 341 in master mode or slave mode. 343 3.6. Normal and High Priority Counters 345 The 100VG-AnyLAN interface MIB does not provide normal priority 346 transmit counters. Standardization of normal priority transmit 347 counters could not be justified -- ifOutUcastPkts, 348 ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets, 349 dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets should 350 suffice. More precisely, the number of normal priority frames 351 transmitted can be calculated as: 353 outNormPriorityFrames = ifOutUcastPkts + 354 ifOutMulticastPkts + 355 ifOutBroadcastPkts - 356 dot12OutHighPriorityFrames 358 The number of normal priority octets transmitted can be calculated 359 as: 361 outNormPriorityOctets = ifOutOctets - 362 dot12OutHighPriorityOctets 364 On the other hand, normal priority receive counters are provided. 365 The main reason for this is that the normal priority and high 366 priority counters include errored frames, whereas the ifIn*Pkts and 367 ifInOctets do not include errored frames. dot12InNormPriorityFrames 368 could be calculated, but the calculation is tedious: 370 inNormPriorityFrames = ifInUcastPkts + 371 ifInMulticastPkts + 372 ifInBroadcastPkts + 373 dot12InNullAddressedFrames + 374 ifInErrors + 375 ifInDiscards + 376 ifInUnknownProtos - 377 dot12InHighPriorityFrames 379 dot12InNormPriorityOctets includes octets in unreadable frames, which 380 is not available elsewhere. The number of octets in unreadable 381 frames can be calculated as: 383 octetsInUnreadableFrames = dot12InNormPriorityOctets + 384 dot12InHighPriorityOctets - 385 ifInOctets 387 Also, the total bandwidth utilization by this interface can be 388 calculated as: 390 utilization = dot12InNormPriorityOctets + 391 dot12InHighPriorityOctets + 392 ifOutOctets 394 In other words, the normal priority receive counters were deemed 395 useful, whereas the normal priority transmit counters can be easily 396 calculated from other available counters. 398 3.7. Mapping of IEEE 802.12 Managed Objects 400 The following table lists all the managed objects defined for 401 oEndNode in the IEEE 802.12 Standard, and the corresponding SNMP 402 objects. 404 IEEE 802.12 Managed Object Corresponding SNMP Object 405 oEndNode 406 .aBroadcastFramesReceived IF-MIB - ifInBroadcastPkts 407 .aBroadcastFramesTransmitted IF-MIB - ifOutBroadcastPkts 408 .aDataErrorFramesReceived dot12InDataErrors 409 .aDesiredFramingType dot12DesiredFramingType 410 .aDesiredPromiscuousStatus dot12DesiredPromiscStatus 411 .aFramesTransmitted IF-MIB - ifOutUCastPkts + 412 ifOutMulticastPkts + 413 ifOutBroadcastPkts 414 .aFramingCapability dot12FramingCapability 415 .aFunctionalAddresses IF-MIB - ifRcvAddressTable 416 .aHighPriorityFramesReceived dot12InHighPriorityFrames 417 .aHighPriorityFramesTransmitted dot12OutHighPriorityFrames 418 .aHighPriorityOctetsReceived dot12InHighPriorityOctets or 419 dot12InHCHighPriorityOctets 420 .aHighPriorityOctetsTransmitted dot12OutHighPriorityOctets or 421 dot12OutHCHighPriorityOctets 422 .aIPMFramesReceived dot12InIPMErrors 423 .aLastTrainingConfig dot12LastTrainingConfig 424 .aMACID IF-MIB - ifIndex 425 .aMACStatus dot12Status 426 .aMACVersion dot12TrainingVersion 427 .aMediaType 428 Tranceiver MIB issue 429 .aMulticastFramesReceived IF-MIB - ifInMulticastPkts 430 .aMulticastFramesTransmitted IF-MIB - ifOutMulticastPkts 431 .aMulticastReceiveStatus IF-MIB - ifRcvAddressTable 432 .aNormalPriorityFramesReceived dot12InNormPriorityFrames 433 .aNormalPriorityOctetsReceived dot12InNormPriorityOctets or 434 dot12InHCNormPriorityOctets 435 .aNullAddressedFramesReceived dot12InNullAddressedFrames 436 .aOctetsTransmitted IF-MIB - ifOutOctets or 437 ifHCOutOctets 438 .aOversizeFramesReceived dot12InOversizeFrameErrors 439 .aReadableFramesReceived IF-MIB - ifInUcastPkts + 440 ifInMulticastPkts + 441 ifInBroadcastPkts 442 .aReadableOctetsReceived IF-MIB - ifInOctets or 443 ifHCInOctets 444 .aReadMulticastList IF-MIB - ifRcvAddressTable 445 .aReadWriteMACAddress IF-MIB - ifPhysAddress 446 .aTransitionsIntoTraining dot12TransitionIntoTrainings 447 .acAddGroupAddress IF-MIB - ifRcvAddressTable 448 .acClose dot12Commands: 'close' 449 .acDeleteGroupAddress IF-MIB - ifRcvAddressTable 450 .acExecuteSelftest IF-MIB - ifAdminStatus 451 .acInitializeMAC dot12Commands: 'reset' 452 .acOpen dot12Commands: 'open' 454 4. Definitions 456 DOT12-IF-MIB DEFINITIONS ::= BEGIN 458 IMPORTS 459 experimental, Counter32, Counter64, OBJECT-TYPE, 460 MODULE-IDENTITY 461 FROM SNMPv2-SMI 462 MODULE-COMPLIANCE, OBJECT-GROUP 463 FROM SNMPv2-CONF 464 ifIndex 465 FROM IF-MIB; 467 dot12MIB MODULE-IDENTITY 468 LAST-UPDATED "9511072032Z" 469 ORGANIZATION "IETF 100VG-AnyLAN MIB Working Group" 470 CONTACT-INFO 471 " John Flick 473 Postal: Hewlett Packard Company 474 8000 Foothills Blvd. M/S 5556 475 Roseville, CA 95747-5556 476 Tel: +1 916 785 4018 477 Fax: +1 916 785 3583 479 E-mail: johnf@hprnd.rose.hp.com" 480 DESCRIPTION 481 "This MIB module describes objects for 482 managing 100VG-AnyLAN interfaces." 483 ::= { experimental 63 } 484 -- move to { transmission 55 } 486 dot12MIBObjects OBJECT IDENTIFIER ::= { dot12MIB 1 } 488 dot12ConfigTable OBJECT-TYPE 489 SYNTAX SEQUENCE OF Dot12ConfigEntry 490 MAX-ACCESS not-accessible 491 STATUS current 492 DESCRIPTION 493 "Configuration information for a collection of 494 802.12 interfaces attached to a particular 495 system." 496 ::= { dot12MIBObjects 1 } 498 dot12ConfigEntry OBJECT-TYPE 499 SYNTAX Dot12ConfigEntry 500 MAX-ACCESS not-accessible 501 STATUS current 502 DESCRIPTION 503 "Configuration for a particular interface to an 504 802.12 medium." 505 INDEX { ifIndex } 506 ::= { dot12ConfigTable 1 } 508 Dot12ConfigEntry ::= 509 SEQUENCE { 510 dot12DesiredFramingType INTEGER, 511 dot12FramingCapability INTEGER, 512 dot12DesiredPromiscStatus INTEGER, 513 dot12TrainingVersion INTEGER, 514 dot12LastTrainingConfig OCTET STRING, 515 dot12Commands INTEGER, 516 dot12Status INTEGER, 517 dot12CurrentFramingType INTEGER, 518 dot12ControlMode INTEGER 519 } 521 dot12DesiredFramingType OBJECT-TYPE 522 SYNTAX INTEGER { 523 frameType88023(1), 524 frameType88025(2), 525 frameTypeEither(3) 526 } 527 MAX-ACCESS read-write 528 STATUS current 529 DESCRIPTION 530 "The type of framing which will be requested by 531 the interface during the next interface MAC 532 initialization or open action. 534 In master mode, this is the framing mode which 535 will be granted by the interface. Note that 536 for a master mode interface, this object must be 537 equal to 'frameType88023' or 'frameType88025', 538 since a master mode interface cannot grant 539 'frameTypeEither'." 540 REFERENCE 541 "IEEE 802.12, Layer Management, 13.2.5.2.1, 542 aDesiredFramingType." 543 ::= { dot12ConfigEntry 1 } 545 dot12FramingCapability OBJECT-TYPE 546 SYNTAX INTEGER { 547 frameType88023(1), 548 frameType88025(2), 549 frameTypeEither(3) 551 } 552 MAX-ACCESS read-only 553 STATUS current 554 DESCRIPTION 555 "The type of framing this interface is capable of 556 supporting." 557 REFERENCE 558 "IEEE 802.12, Layer Management, 13.2.5.2.1, 559 aFramingCapability." 560 ::= { dot12ConfigEntry 2 } 562 dot12DesiredPromiscStatus OBJECT-TYPE 563 SYNTAX INTEGER { 564 singleAddressMode(1), 565 promiscuousMode(2) 566 } 567 MAX-ACCESS read-write 568 STATUS current 569 DESCRIPTION 570 "This object is used to select the promiscuous 571 mode that this interface will request in the next 572 training packet issued on this interface. 573 Whether the repeater grants the requested mode 574 must be verified by examining the state of the PP 575 bits in the corresponding instance of 576 dot12LastTrainingConfig. 578 In master mode, this object controls whether or 579 not promiscuous mode will be granted by the 580 interface when requested by the lower level 581 device. 583 Note that this object indicates the desired mode 584 for the next time the interface trains. The 585 currently active mode will be reflected in 586 dot12LastTrainingConfig and in ifPromiscuousMode." 587 REFERENCE 588 "IEEE 802.12, Layer Management, 13.2.5.2.1, 589 aDesiredPromiscuousStatus." 590 ::= { dot12ConfigEntry 3 } 592 dot12TrainingVersion OBJECT-TYPE 593 SYNTAX INTEGER (0..7) 594 MAX-ACCESS read-only 595 STATUS current 596 DESCRIPTION 597 "The value that will be used in the version bits 598 (vvv bits) in training frames on this interface. 600 This is the highest version number supported by 601 this MAC." 602 REFERENCE 603 "IEEE 802.12, Layer Management, 13.2.5.2.1, 604 aMACVersion." 605 ::= { dot12ConfigEntry 4 } 607 dot12LastTrainingConfig OBJECT-TYPE 608 SYNTAX OCTET STRING (SIZE(2)) 609 MAX-ACCESS read-only 610 STATUS current 611 DESCRIPTION 612 "This 16 bit field contains the configuration 613 bits from the most recent error-free training 614 frame received during training on this interface. 615 Training request frames are received when in 616 master mode, while training response frames are 617 received in slave mode. 619 First Octet: Second Octet: 621 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 622 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 623 |v|v|v|D|C|N|0|0| |0|0|0|F|F|P|P|R| 624 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 626 vvv: The version of the 802.12 training 627 protocol with which the device at the 628 other end of the link is compliant 629 D: 0 = No duplicate address has been 630 detected. This bit is always zero 631 in training request frames. 632 1 = Duplicate address has been detected 633 C: 0 = The requested configuration is 634 compatible with the port. This bit 635 is always zero in training request 636 frames. 637 1 = The requested configuration is not 638 compatible with the port. 639 N: 0 = Access will be allowed, providing 640 the configuration is compatible (C 641 = 0). This bit is always zero in 642 training request frames. 643 1 = Access is not granted because of 644 security restrictions 645 FF: 00 = frameType88023 646 01 = frameType88025 647 10 = reserved 648 11 = frameTypeEither (this value is seen 649 only when in master mode) 650 PP: 00 = singleAddressMode 651 01 = promiscuousMode 652 10 = reserved 653 11 = reserved 654 R: 0 = Access as an end node 655 1 = Access as a repeater (this value is 656 seen only when in master mode and 657 the other end of the link connects 658 to a repeater) 660 Note that dot12Status must be examined to see if 661 any error-free training frames have been 662 received." 663 REFERENCE 664 "IEEE 802.12, Layer Management, 13.2.5.2.1, 665 aLastTrainingConfig." 666 ::= { dot12ConfigEntry 5 } 668 -- { dot12ConfigEntry 6 } is unassigned 670 dot12Commands OBJECT-TYPE 671 SYNTAX INTEGER { 672 noOp(1), 673 open(2), 674 reset(3), 675 close(4) 676 } 677 MAX-ACCESS read-write 678 STATUS current 679 DESCRIPTION 680 "If the current value of dot12Status is 'closed', 681 setting the value of this object to 'open' will 682 change the corresponding instance of MIB-II's 683 ifAdminStatus to 'up', cause this interface to 684 enter the 'opening' state, and will cause training 685 to be initiated on this interface. The progress 686 and success of the open is given by the values of 687 the dot12Status object. Setting this object to 688 'open' when dot12Status has a value other than 689 'closed' has no effect. 691 Setting the corresponding instance of ifAdminStatus 692 to 'up' when the current value of dot12Status is 693 'closed' will have the same effect as setting this 694 object to 'open'. Setting ifAdminStatus to 'up' 695 when dot12Status has a value other than 'closed' 696 has no effect. 698 Setting the value of this object to 'close' will 699 move this interface into the 'closed' state and 700 cause all transmit and receive actions to stop. 701 This object will then have to be set to 'open' in 702 order to reinitiate training. 704 Setting the corresponding instance of ifAdminStatus 705 to 'down' will have the same effect as setting this 706 object to 'close'. 708 Setting the value of this object to 'reset' when 709 the current value of dot12Status has a value other 710 than 'closed' will reset the interface. On a 711 reset, all MIB counters should retain their values. 712 This will cause the MAC to initiate an 713 acInitializeMAC action as specified in IEEE 802.12. 714 This will cause training to be reinitiated on this 715 interface. Setting this object to 'reset' when 716 dot12Status has a value of 'closed' has no effect. 717 Setting this object to 'reset' has no effect on the 718 corresponding instance of ifAdminStatus. 720 Setting the value of this object to 'noOp' has no 721 effect. 723 When read, this object will always have a value 724 of 'noOp'." 725 REFERENCE 726 "IEEE 802.12, Layer Management, 13.2.5.2.2, 727 acOpen, acClose, acInitializeMAC. 728 Also, RFC1231 IEEE802.5 Token Ring MIB, 729 dot5Commands." 730 ::= { dot12ConfigEntry 7 } 732 dot12Status OBJECT-TYPE 733 SYNTAX INTEGER { 734 opened(1), 735 closed(2), 736 opening(3), 737 openFailure(5), 738 linkFailure(6) 739 } 740 MAX-ACCESS read-only 741 STATUS current 742 DESCRIPTION 743 "The current interface status with respect to 744 training. One of the following values: 746 opened - Training has completed 747 successfully. 748 closed - MAC has been disabled by 749 setting dot12Commands to 750 'close'. 751 opening - MAC is in training. Training 752 signals have been received. 753 openFailure - Passed 24 error-free packets, 754 but there is a problem, noted 755 in the training configuration 756 bits (dot12LastTrainingConfig). 757 linkFailure - Training signals not received, 758 or could not pass 24 error-free 759 packets. 761 Whenever the dot12Commands object is set to 762 'close' or ifAdminStatus is set to 'down', the MAC 763 will go silent, dot12Status will be 'closed', and 764 ifOperStatus will be 'down'. 766 When the value of this object is equal to 'closed' 767 and the dot12Commands object is set to 'open' or 768 the ifAdminStatus object is set to 'up', training 769 will be initiated on this interface. When the 770 value of this object is not equal to 'closed' and 771 the dot12Commands object is set to 'reset', 772 training will be reinitiated on this interface. 773 Note that sets of some other objects (e.g. 774 dot12ControlMode) or external events (e.g. MAC 775 protocol violations) may also cause training to be 776 reinitiated on this interface. 778 When training is initiated or reinitiated on an 779 interface, the end node will send Training_Up to 780 the master and initially go to the 'linkFailure' 781 state and ifOperStatus will go to 'down'. 782 When the master sends back Training_Down, 783 dot12Status will change to the 'opening' state, 784 and training packets will be transferred. 786 After all of the training packets have been 787 passed, dot12Status will change to 'linkFailure' 788 if 24 consecutive error-free packets were not 789 passed, 'opened' if 24 consecutive error-free 790 packets were passed and the training 791 configuration bits were OK, or 'openFailure' if 792 there were 24 consecutive error-free packets, but 793 there was a problem with the training 794 configuration bits. 796 When in the 'openFailure' state, the 797 dot12LastTrainingConfig object will contain the 798 configuration bits from the last training 799 packet which can be examined to determine the 800 exact reason for the training configuration 801 failure. 803 If training did not succeed (dot12Status is 804 'linkFailure' or 'openFailure), the entire 805 process will be restarted after 806 MAC_Retraining_Delay_Timer seconds. 808 If training does succeed (dot12Status changes to 809 'opened'), ifOperStatus will change to 'up'. If 810 training does not succeed (dot12Status changes to 811 'linkFailure' or 'openFailure'), ifOperStatus will 812 remain 'down'." 813 REFERENCE 814 "IEEE 802.12, Layer Management, 13.2.5.2.1, 815 aMACStatus." 816 ::= { dot12ConfigEntry 8 } 818 dot12CurrentFramingType OBJECT-TYPE 819 SYNTAX INTEGER { 820 frameType88023(1), 821 frameType88025(2), 822 frameTypeUnknown(3) 823 } 824 MAX-ACCESS read-only 825 STATUS current 826 DESCRIPTION 827 "When dot12DesiredFramingType is one of 828 'frameType88023' or 'frameType88025', this is the 829 type of framing asserted by the interface. 831 When dot12DesiredFramingType is 'frameTypeEither', 832 dot12CurrentFramingType shall be one of 833 'frameType88023' or 'frameType88025' when the 834 dot12Status is 'opened'. When the dot12Status is 835 anything other than 'opened', 836 dot12CurrentFramingType shall take the value of 837 'frameTypeUnknown'." 838 ::= { dot12ConfigEntry 9 } 840 dot12ControlMode OBJECT-TYPE 841 SYNTAX INTEGER { 842 masterMode(1), 843 slaveMode(2), 844 learn(3) 845 } 846 MAX-ACCESS read-write 847 STATUS current 848 DESCRIPTION 849 "This object is used to configure and report 850 whether or not this interface is operating in 851 master mode. In a Demand Priority network, end 852 node interfaces typically operate in slave mode, 853 while switch interfaces may control the Demand 854 Priority protocol and operate in master mode. 856 This object may be implemented as a read-only 857 object by those agents and interfaces that do not 858 implement software control of master mode. In 859 particular, interfaces that cannot operate in 860 master mode, and interfaces on which master mode 861 is controlled by a pushbutton on the device, 862 should implement this object read-only. 864 Some interfaces do not require network management 865 configuration of this feature and can autosense 866 whether to use master mode or slave mode. The 867 value 'learn' is used for that purpose. While 868 autosense is taking place, the value 'learn' is 869 returned. 871 A network management operation which modifies the 872 value of dot12ControlMode causes the interface 873 to retrain." 874 ::= { dot12ConfigEntry 10 } 876 dot12StatTable OBJECT-TYPE 877 SYNTAX SEQUENCE OF Dot12StatEntry 878 MAX-ACCESS not-accessible 879 STATUS current 880 DESCRIPTION 881 "Statistics for a collection of 802.12 interfaces 882 attached to a particular system." 883 ::= { dot12MIBObjects 2 } 885 dot12StatEntry OBJECT-TYPE 886 SYNTAX Dot12StatEntry 887 MAX-ACCESS not-accessible 888 STATUS current 889 DESCRIPTION 890 "Statistics for a particular interface to an 891 802.12 medium. The receive statistics in this 892 table apply only to packets received by this 893 station (i.e., packets whose destination address 894 is either the local station address, the 895 broadcast address, or a multicast address that 896 this station is receiving, unless the station is 897 in promiscuous mode)." 898 INDEX { ifIndex } 899 ::= { dot12StatTable 1 } 901 Dot12StatEntry ::= 902 SEQUENCE { 903 dot12InHighPriorityFrames Counter32, 904 dot12InHighPriorityOctets Counter32, 905 dot12InNormPriorityFrames Counter32, 906 dot12InNormPriorityOctets Counter32, 907 dot12InIPMErrors Counter32, 908 dot12InOversizeFrameErrors Counter32, 909 dot12InDataErrors Counter32, 910 dot12InNullAddressedFrames Counter32, 911 dot12OutHighPriorityFrames Counter32, 912 dot12OutHighPriorityOctets Counter32, 913 dot12TransitionIntoTrainings Counter32, 914 dot12HCInHighPriorityOctets Counter64, 915 dot12HCInNormPriorityOctets Counter64, 916 dot12HCOutHighPriorityOctets Counter64 917 } 919 dot12InHighPriorityFrames OBJECT-TYPE 920 SYNTAX Counter32 921 MAX-ACCESS read-only 922 STATUS current 923 DESCRIPTION 924 "This object is a count of high priority frames 925 that have been received on this interface. 926 Includes both good and bad high priority frames, 927 as well as high priority training frames. Does 928 not include normal priority frames which were 929 priority promoted." 930 REFERENCE 931 "IEEE 802.12, Layer Management, 13.2.5.2.1, 932 aHighPriorityFramesReceived." 933 ::= { dot12StatEntry 1 } 935 dot12InHighPriorityOctets OBJECT-TYPE 936 SYNTAX Counter32 937 MAX-ACCESS read-only 938 STATUS current 939 DESCRIPTION 940 "This object is a count of the number of octets 941 contained in high priority frames that have been 942 received on this interface. This counter is 943 incremented by OctetCount for each frame received 944 on this interface which is counted by 945 dot12InHighPriorityFrames. 947 Note that this counter will roll over very 948 quickly. It is provided for backward 949 compatibility for Network Management protocols 950 that do not support 64 bit counters (e.g. SNMP 951 version 1)." 952 REFERENCE 953 "IEEE 802.12, Layer Management, 13.2.5.2.1, 954 aHighPriorityOctetsReceived." 955 ::= { dot12StatEntry 2 } 957 dot12InNormPriorityFrames OBJECT-TYPE 958 SYNTAX Counter32 959 MAX-ACCESS read-only 960 STATUS current 961 DESCRIPTION 962 "This object is a count of normal priority frames 963 that have been received on this interface. 964 Includes both good and bad normal priority 965 frames, as well as normal priority training 966 frames and normal priority frames which were 967 priority promoted." 968 REFERENCE 969 "IEEE 802.12, Layer Management, 13.2.5.2.1, 970 aNormalPriorityFramesReceived." 971 ::= { dot12StatEntry 3 } 973 dot12InNormPriorityOctets OBJECT-TYPE 974 SYNTAX Counter32 975 MAX-ACCESS read-only 976 STATUS current 977 DESCRIPTION 978 "This object is a count of the number of octets 979 contained in normal priority frames that have 980 been received on this interface. This counter is 981 incremented by OctetCount for each frame received 982 on this interface which is counted by 983 dot12InNormPriorityFrames. 985 Note that this counter will roll over very 986 quickly. It is provided for backward 987 compatibility for Network Management protocols 988 that do not support 64 bit counters (e.g. SNMP 989 version 1)." 990 REFERENCE 991 "IEEE 802.12, Layer Management, 13.2.5.2.1, 992 aNormalPriorityOctetsReceived." 993 ::= { dot12StatEntry 4 } 995 dot12InIPMErrors OBJECT-TYPE 996 SYNTAX Counter32 997 MAX-ACCESS read-only 998 STATUS current 999 DESCRIPTION 1000 "This object is a count of the number of frames 1001 that have been received on this interface with an 1002 invalid packet marker and no PMI errors. A 1003 repeater will write an invalid packet marker to 1004 the end of a frame containing errors as it is 1005 forwarded through the repeater to the other 1006 ports. This counter is incremented by one for 1007 each frame received on this interface which has 1008 had an invalid packet marker added to the end of 1009 the frame." 1010 REFERENCE 1011 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1012 aIPMFramesReceived." 1013 ::= { dot12StatEntry 5 } 1015 dot12InOversizeFrameErrors OBJECT-TYPE 1016 SYNTAX Counter32 1017 MAX-ACCESS read-only 1018 STATUS current 1019 DESCRIPTION 1020 "This object is a count of oversize frames 1021 received on this interface. This counter is 1022 incremented by one for each frame received on 1023 this interface whose OctetCount is larger than 1024 the maximum legal frame size. The frame size 1025 which causes this counter to increment is 1026 dependent on the current framing type." 1027 REFERENCE 1028 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1029 aOversizeFramesReceived." 1030 ::= { dot12StatEntry 6 } 1032 dot12InDataErrors OBJECT-TYPE 1033 SYNTAX Counter32 1034 MAX-ACCESS read-only 1035 STATUS current 1036 DESCRIPTION 1037 "This object is a count of errored frames 1038 received on this interface. This counter is 1039 incremented by one for each frame received on 1040 this interface with any of the following errors: 1041 bad FCS (with no IPM), PMI errors (excluding 1042 frames with an IPM as the only PMI error), 1043 undersize, bad start of frame delimiter, or bad 1044 end of packet marker. Does not include frames 1045 counted by dot12InIPMErrors, 1046 dot12InNullAddressedFrames, or 1047 dot12InOversizeFrameErrors. 1049 This counter indicates problems with the cable 1050 directly attached to this interface, while 1051 dot12InIPMErrors indicates problems with remote 1052 cables." 1053 REFERENCE 1054 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1055 aDataErrorFramesReceived." 1056 ::= { dot12StatEntry 7 } 1058 dot12InNullAddressedFrames OBJECT-TYPE 1059 SYNTAX Counter32 1060 MAX-ACCESS read-only 1061 STATUS current 1062 DESCRIPTION 1063 "This object is a count of null addressed frames 1064 received on this interface. This counter is 1065 incremented by one for each frame received on 1066 this interface with a destination MAC address 1067 consisting of all zero bits. Both void and 1068 training frames are included in this counter. 1070 Note that since this station would normally not 1071 receive null addressed frames, this counter is 1072 only incremented when this station is operating 1073 in promiscuous mode." 1074 REFERENCE 1075 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1076 aNullAddressedFramesReceived." 1077 ::= { dot12StatEntry 8 } 1079 dot12OutHighPriorityFrames OBJECT-TYPE 1080 SYNTAX Counter32 1081 MAX-ACCESS read-only 1082 STATUS current 1083 DESCRIPTION 1084 "This counter is incremented by one for each high 1085 priority frame successfully transmitted out this 1086 interface." 1087 REFERENCE 1088 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1089 aHighPriorityFramesTransmitted." 1090 ::= { dot12StatEntry 9 } 1092 dot12OutHighPriorityOctets OBJECT-TYPE 1093 SYNTAX Counter32 1094 MAX-ACCESS read-only 1095 STATUS current 1096 DESCRIPTION 1097 "This counter is incremented by OctetCount for 1098 each frame counted by dot12OutHighPriorityFrames. 1100 Note that this counter will roll over very 1101 quickly. It is provided for backward 1102 compatibility for Network Management protocols 1103 that do not support 64 bit counters (e.g. SNMP 1104 version 1)." 1105 REFERENCE 1106 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1107 aHighPriorityOctetsTransmitted." 1108 ::= { dot12StatEntry 10 } 1110 dot12TransitionIntoTrainings OBJECT-TYPE 1111 SYNTAX Counter32 1112 MAX-ACCESS read-only 1113 STATUS current 1114 DESCRIPTION 1115 "This object is a count of the number of times 1116 this interface has entered the training state. 1117 This counter is incremented by one each time 1118 dot12Status transitions to 'linkFailure' from any 1119 state other than 'opening' or 'openFailure'." 1120 REFERENCE 1121 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1122 aTransitionsIntoTraining." 1123 ::= { dot12StatEntry 11 } 1125 dot12HCInHighPriorityOctets OBJECT-TYPE 1126 SYNTAX Counter64 1127 MAX-ACCESS read-only 1128 STATUS current 1129 DESCRIPTION 1130 "This object is a count of the number of octets 1131 contained in high priority frames that have been 1132 received on this interface. This counter is 1133 incremented by OctetCount for each frame received 1134 on this interface which is counted by 1135 dot12InHighPriorityFrames. 1137 This counter is a 64 bit version of 1138 dot12InHighPriorityOctets. It should be used by 1139 Network Management protocols which support 64 bit 1140 counters (e.g. SNMPv2)." 1141 REFERENCE 1142 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1143 aHighPriorityOctetsReceived." 1144 ::= { dot12StatEntry 12 } 1146 dot12HCInNormPriorityOctets OBJECT-TYPE 1147 SYNTAX Counter64 1148 MAX-ACCESS read-only 1149 STATUS current 1150 DESCRIPTION 1151 "This object is a count of the number of octets 1152 contained in normal priority frames that have 1153 been received on this interface. This counter is 1154 incremented by OctetCount for each frame received 1155 on this interface which is counted by 1156 dot12InNormPriorityFrames. 1158 This counter is a 64 bit version of 1159 dot12InNormPriorityOctets. It should be used by 1160 Network Management protocols which support 64 bit 1161 counters (e.g. SNMPv2)." 1162 REFERENCE 1163 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1164 aNormalPriorityOctetsReceived." 1165 ::= { dot12StatEntry 13 } 1167 dot12HCOutHighPriorityOctets OBJECT-TYPE 1168 SYNTAX Counter64 1169 MAX-ACCESS read-only 1170 STATUS current 1171 DESCRIPTION 1172 "This counter is incremented by OctetCount for 1173 each frame counted by dot12OutHighPriorityFrames. 1175 This counter is a 64 bit version of 1176 dot12OutHighPriorityOctets. It should be used by 1177 Network Management protocols which support 64 bit 1178 counters (e.g. SNMPv2)." 1179 REFERENCE 1180 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1181 aHighPriorityOctetsTransmitted." 1182 ::= { dot12StatEntry 14 } 1184 -- conformance information 1186 dot12Conformance OBJECT IDENTIFIER ::= { dot12MIB 2 } 1188 dot12Compliances OBJECT IDENTIFIER ::= { dot12Conformance 1 } 1189 dot12Groups OBJECT IDENTIFIER ::= { dot12Conformance 2 } 1191 -- compliance statements 1193 dot12Compliance MODULE-COMPLIANCE 1194 STATUS current 1195 DESCRIPTION 1196 "The compliance statement for managed network 1197 entities that have 802.12 interfaces." 1199 MODULE -- this module 1200 MANDATORY-GROUPS { dot12ConfigGroup, dot12StatsGroup } 1202 OBJECT dot12DesiredFramingType 1203 MIN-ACCESS read-only 1204 DESCRIPTION 1205 "Write access to this object is not required." 1207 OBJECT dot12DesiredPromiscStatus 1208 MIN-ACCESS read-only 1209 DESCRIPTION 1210 "Write access to this object is not required." 1212 OBJECT dot12Commands 1213 MIN-ACCESS read-only 1214 DESCRIPTION 1215 "Write access to this object is not required." 1217 OBJECT dot12ControlMode 1218 MIN-ACCESS read-only 1219 DESCRIPTION 1220 "Write access to this object is not required." 1221 ::= { dot12Compliances 1 } 1223 -- units of conformance 1224 dot12ConfigGroup OBJECT-GROUP 1225 OBJECTS { dot12DesiredFramingType, 1226 dot12FramingCapability, 1227 dot12DesiredPromiscStatus, 1228 dot12TrainingVersion, 1229 dot12LastTrainingConfig, 1230 dot12Commands, dot12Status, 1231 dot12CurrentFramingType, 1232 dot12ControlMode } 1233 STATUS current 1234 DESCRIPTION 1235 "A collection of objects for managing the status 1236 and configuration of IEEE 802.12 interfaces." 1237 ::= { dot12Groups 1 } 1239 dot12StatsGroup OBJECT-GROUP 1240 OBJECTS { dot12InHighPriorityFrames, 1241 dot12InHighPriorityOctets, 1242 dot12InNormPriorityFrames, 1243 dot12InNormPriorityOctets, 1244 dot12InIPMErrors, 1245 dot12InOversizeFrameErrors, 1246 dot12InDataErrors, 1247 dot12InNullAddressedFrames, 1248 dot12OutHighPriorityFrames, 1249 dot12OutHighPriorityOctets, 1250 dot12TransitionIntoTrainings, 1251 dot12HCInHighPriorityOctets, 1252 dot12HCInNormPriorityOctets, 1253 dot12HCOutHighPriorityOctets } 1254 STATUS current 1255 DESCRIPTION 1256 "A collection of objects providing statistics for 1257 IEEE 802.12 interfaces." 1258 ::= { dot12Groups 2 } 1260 END 1262 5. Acknowledgements 1264 This document was produced by the IETF 100VG-AnyLAN Working Group. 1265 It is based on the work of IEEE 802.12. 1267 6. References 1269 [1] Information processing systems - Open Systems Interconnection - 1270 Specification of Abstract Syntax Notation One (ASN.1), 1271 International Organization for Standardization. International 1272 Standard 8824 (December, 1987). 1274 [2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1275 of Management Information for version 2 of the Simple Network 1276 Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., 1277 Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1278 University, April 1993. 1280 [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1281 Conventions for version 2 of the Simple Network Management 1282 Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN 1283 Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1284 University, April 1993. 1286 [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1287 "Conformance Statements for version 2 of the Simple Network 1288 Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., 1289 Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1290 University, April 1993. 1292 [5] McCloghrie, K., and M. Rose, "Management Information Base for 1293 Network Management of TCP/IP-based internets - MIB-II", STD 17, 1294 RFC 1213, Hughes LAN Systems, Performance Systems International, 1295 March 1991. 1297 [6] IEEE, "Demand Priority Access Method, Physical Layer and Repeater 1298 Specifications for 100 Mb/s Operation", IEEE Standard 802.12" 1300 [7] McCloghrie, K., and Kastenholz, F., "Evolution of the Interfaces 1301 Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, 1302 January 1994. 1304 [8] McCloghrie, K., Baker, F., and Decker, E., "IEEE 802.5 Station 1305 Source Routing MIB using SMIv2", RFC 1749, cisco Systems, Inc., 1306 December, 1994. 1308 7. Security Considerations 1310 Security issues are not discussed in this memo. 1312 8. Author's Address 1314 John Flick 1315 Hewlett Packard Company 1316 8000 Foothills Blvd. M/S 5556 1317 Roseville, CA 95747-5556 1319 Phone: +1 916 785 4018 1320 Email: johnf@hprnd.rose.hp.com 1322 Table of Contents 1324 1. Abstract ................................................... 2 1325 2. Object Definitions ......................................... 2 1326 3. Overview ................................................... 2 1327 3.1. MAC Addresses ............................................ 3 1328 3.2. Relation to RFC 1213 ..................................... 3 1329 3.3. Relation to RFC 1573 ..................................... 3 1330 3.3.1. Layering Model ......................................... 4 1331 3.3.2. Virtual Circuits ....................................... 4 1332 3.3.3. ifTestTable ............................................ 4 1333 3.3.4. ifRcvAddressTable ...................................... 4 1334 3.3.5. ifPhysAddress .......................................... 4 1335 3.3.6. Specific Interface MIB Objects ......................... 5 1336 3.4. Relation to RFC 1749 ..................................... 8 1337 3.5. Master Mode Operation .................................... 8 1338 3.6. Normal and High Priority Counters ........................ 8 1339 3.7. Mapping of IEEE 802.12 Managed Objects ................... 9 1340 4. Definitions ................................................ 11 1341 5. Acknowledgements ........................................... 27 1342 6. References ................................................. 27 1343 7. Security Considerations .................................... 28 1344 8. Author's Address ........................................... 28