idnits 2.17.1 draft-ietf-vgmib-interfaces-mib-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing 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 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 (October 27, 1995) is 10408 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 1282, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1288, 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. -------------------------------------------------------------------------------- 2 Internet Draft IEEE 802.12 Interface MIB October 27 1995 4 Definitions of Managed Objects for IEEE 802.12 Interfaces 6 October 27, 1995 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. Abstract 38 This memo defines an experimental portion of the Management 39 Information Base (MIB) for use with network management protocols in 40 TCP/IP-based internets. In particular, it defines objects for 41 managing network interfaces 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 a 100VG-AnyLAN communications medium. At present, 100VG-AnyLAN 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 ::= { experimental 63 } 71 The definitions presented here are based on the IEEE Standard 802.12, 72 [6] Clause 13 "Layer Management Functions And Services", and Annex E 73 "GDMO Specifications for Demand Priority Managed Objects". 74 Implementors of these MIB objects should note that the IEEE document 75 explicitly describes (in the form of Pascal pseudocode) when, where, 76 and how various MAC attributes are measured. The IEEE document also 77 describes the effects of MAC actions that may be invoked by 78 manipulating instances of the MIB objects defined here. 80 To the extent that some of the attributes defined in [6] are 81 represented by previously defined objects in the Internet-standard 82 MIB [5] or in the Evolution of the Interfaces Group of MIB-II [7], 83 such attributes are not redundantly represented by objects defined in 84 this memo. Among the attributes represented by objects defined in 85 other memos are the number of octets transmitted or received on a 86 particular interface, the MAC address of an interface, and multicast 87 information associated with an interface. 89 3.1. MAC Addresses 91 All representations of MAC addresses in this MIB module, and in other 92 related MIB modules (like RFC 1573), are in "canonical" order defined 93 by 802.1a, i.e., as if it were transmitted least significant bit 94 first. This is true even if the interface is operating in token ring 95 framing mode, which requires MAC addresses to be transmitted most 96 significant bit first. 98 3.2. Relation to RFC 1213 100 This section applies only when this MIB is used in conjunction with 101 the "old" (i.e., pre-RFC 1573) interface group. 103 The relationship between a 100VG-AnyLAN interface and an interface in 104 the context of the Internet-standard MIB is one-to-one. As such, the 105 value of an ifIndex object instance can be directly used to identify 106 corresponding instances of the objects defined herein. 108 3.3. Relation to RFC 1573 110 RFC 1573, the Interface MIB Evolution, requires that any MIB which is 111 an adjunct of the Interface MIB, clarify specific areas within the 112 Interface MIB. These areas are intentionally left vague in RFC 1573 113 to avoid over constraining the MIB, thereby precluding management of 114 certain media-types. 116 An agent which implements this MIB module must support the 117 ifGeneralGroup, ifStackGroup, ifHCPacketGroup, and ifRcvAddressGroup 118 of RFC 1573. 120 Section 3.3 of RFC 1573 enumerates several areas which a media- 121 specific MIB must clarify. In addition, there are some objects in 122 RFC 1573 for which additional clarification of how to apply them to a 123 100VG-AnyLAN interface would be helpful. Each of these areas is 124 addressed in a following subsection. The implementor is referred to 125 RFC 1573 in order to understand the general intent of these areas. 127 3.3.1. Layering Model 129 For the typical usage of this MIB module, there will be no sub-layers 130 "above" or "below" the 802.12 Interface. However, this MIB module 131 does not preclude such layering. 133 3.3.2. Virtual Circuits 135 This medium does not support virtual circuits and this area is not 136 applicable to this MIB. 138 3.3.3. ifTestTable 140 This MIB does not define any tests for media instrumented by this 141 MIB. Implementation of the ifTestTable is not required. An 142 implementation may optionally implement the ifTestTable to execute 143 vendor specific tests. 145 3.3.4. ifRcvAddressTable 147 This table contains all IEEE addresses, unicast, multicast, and 148 broadcast, for which this interface will receive packets and forward 149 them up to a higher layer entity for consumption. In addition, when 150 the interface is using 802.5 framing mode, the ifRcvAddressTable will 151 contain the functional address mask. 153 In the event that the interface is part of a MAC bridge, this table 154 does not include unicast addresses which are accepted for possible 155 forwarding out some other port. This table is explicitly not 156 intended to provide a bridge address filtering mechanism. 158 3.3.5. ifPhysAddress 160 This object contains the IEEE 802.12 address which is placed in the 161 source-address field of any frames that originate at this interface. 162 Usually this will be kept in ROM on the interface hardware. Some 163 systems may set this address via software. 165 In a system where there are several such addresses the designer has a 166 tougher choice. The address chosen should be the one most likely to 167 be of use to network management (e.g. the address placed in ARP 168 responses for systems which are primarily IP systems). 170 If the designer truly can not choose, use of the factory-provided ROM 171 address is suggested. 173 If the address can not be determined, an octet string of zero length 174 should be returned. 176 The address is stored in binary in this object. The address is 177 stored in "canonical" bit order, that is, the Group Bit is positioned 178 as the low-order bit of the first octet. Thus, the first byte of a 179 multicast address would have the bit 0x01 set. This is true even 180 when the interface is using token ring framing mode, which transmits 181 addresses high-order bit first. 183 3.3.6. Specific Interface MIB Objects 185 The following table provides specific implementation guidelines for 186 the interface group objects in the conformance groups listed above. 188 Object Use for an 802.12 Interface 190 ifIndex Each 802.12 interface is represented by an 191 ifEntry. Interface tables in this MIB 192 module are indexed by ifIndex. 194 ifDescr Interface description. 196 ifType The IANA reserved value for 802.12 - 55. 198 ifMtu The value of ifMtu on an 802.12 interface 199 will depend on the type of framing that is 200 in use on that interface. Changing the 201 dot12DesiredFramingType may have the effect 202 of changing ifMtu after the next time that 203 the interface trains. When 204 dot12CurrentFramingType is equal to 205 frameType88023, ifMtu will be equal to 206 1500. When dot12CurrentFramingType is 207 equal to frameType88025, ifMtu will be 208 4464. 210 ifSpeed The speed of the interface in bits per 211 second. For current 802.12 212 implementations, this will be equal to 213 100,000,000 (100 million). 215 ifPhysAddress See Section 3.3.5. 217 ifAdminStatus Write access is not required. Support for 218 'testing' is not required. Setting this 219 object to 'up' will cause dot12Commands to 220 be set to 'open'. Setting this object to 221 'down' will cause dot12Commands to be set 222 to 'close'. Setting dot12Commands to 223 'open' will set this object to 'up'. 224 Setting dot12Commands to 'close' will set 225 this object to 'down'. Setting 226 dot12Commands to 'reset' will have no 227 effect on this object. 229 ifOperStatus When dot12Status is equal to 'opened', this 230 object will be equal to 'up'. When 231 dot12Status is equal to 'closed', 232 'openFailure' or 'linkFailure', this object 233 will be equal to 'down'. When dot12Status 234 is equal to 'opening' this object will be 235 equal to 'testing'. The value 'dormant' 236 has no meaning for an IEEE 802.12 237 interface. 239 ifLastChange Refer to [7]. 241 ifInOctets The number of octets in valid MAC frames 242 received on this interface, including the 243 MAC header and FCS. 245 ifInUcastPkts Refer to [7]. 247 ifInDiscards Refer to [7]. 249 ifInErrors The sum for this interface of 250 dot12InIPMErrors, 251 dot12InOversizeFrameErrors, 252 dot12InDataErrors, and any additional 253 internal errors that may occur in an 254 implementation. 256 ifInUnknownProtos Refer to [7]. 258 ifOutOctets The number of octets transmitted in MAC 259 frames on this interface, including the MAC 260 header and FCS. 262 ifOutUcastPkts Refer to [7]. 264 ifOutDiscards Refer to [7]. 266 ifOutErrors The number of implementation-specific 267 internal transmit errors on this interface. 269 ifName Locally-significant textual name for the 270 interface (e.g. vg0). 272 ifInMulticastPkts Refer to [7]. When dot12CurrentFramingType 273 is frameType88025, this count includes 274 packets addressed to functional addresses. 276 ifInBroadcastPkts Refer to [7]. 278 ifOutMulticastPkts Refer to [7]. When dot12CurrentFramingType 279 is frameType88025, this count includes 280 packets addressed to functional addresses. 282 ifOutBroadcastPkts Refer to [7]. 284 ifHCInOctets 64-bit version of ifInOctets. 286 ifHCOutOctets 64-bit version of ifOutOctets 288 ifHC*Pkts Not required for 100 MBit interfaces. 289 Future IEEE 802.12 interfaces which operate 290 at higher speeds may require implemenation 291 of these counters, but such interfaces are 292 beyond the scope of this memo. 294 ifLinkUpDownTrapEnable Refer to [7]. Default is 'enabled'. 296 ifHighSpeed The speed of the interface in millions of 297 bits per second. For current 802.12 298 implementations, this will be equal to 100. 300 ifPromiscuousMode Reflects whether the interface has 301 successfully trained and is currently 302 operating in promiscuous mode. 303 dot12DesiredPromiscStatus is used to select 304 the promiscuous mode to be requested in the 305 next training attempt. Setting 306 ifPromiscuousMode will update 307 dot12DesiredPromiscStatus and cause the 308 interface to attempt to retrain using the 309 new promiscuous mode. After the interface 310 has retrained, ifPromiscuousMode will 311 reflect the mode that is in use, not the 312 mode that was requested. 314 ifConnectorPresent This will normally be 'true'. 316 ifStackHigherLayer Refer to section 3.3.1 317 ifStackLowerLayer 318 ifStackStatus 320 ifRcvAddressAddress Refer to section 3.3.4. 321 ifRcvAddressStatus 322 ifRcvAddressType 324 3.4. Relation to RFC 1749 326 When an IEEE 802.12 interface is operating in token ring framing 327 mode, and the end node supports token ring source routing, the agent 328 should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB 329 [8] for those interfaces. 331 3.5. Master Mode Operation 333 In a 100VG-AnyLAN network, "master" devices act as network 334 controllers to decide when to grant requesting end-nodes permission 335 to transmit. These master devices may be repeaters, or other active 336 controller devices such as switches. 338 Devices which do not act as network controllers, such as end-nodes or 339 passive switches, are considered to be operating in "slave" mode. 341 The dot12ControlMode object indicates if the interface is operating 342 in master mode or slave mode. 344 3.6. Normal and High Priority Counters 346 The 100VG-AnyLAN interface MIB does not provide normal priority 347 transmit counters. Standardization of normal priority transmit 348 counters could not be justified -- ifOutUcastPkts, 349 ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets, 350 dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets should 351 suffice. More precisely, the number of normal priority frames 352 transmitted can be calculated as: 354 outNormPriorityFrames = ifOutUcastPkts + 355 ifOutMulticastPkts + 356 ifOutBroadcastPkts - 357 dot12OutHighPriorityFrames 359 The number of normal priority octets transmitted can be calculated 360 as: 362 outNormPriorityOctets = ifOutOctets - 363 dot12OutHighPriorityOctets 365 On the other hand, normal priority receive counters are provided. 366 The main reason for this is that the normal priority and high 367 priority counters include errored frames, whereas the ifIn*Pkts and 368 ifInOctets do not include errored frames. dot12InNormPriorityFrames 369 could be calculated, but the calculation is tedious: 371 inNormPriorityFrames = ifInUcastPkts + 372 ifInMulticastPkts + 373 ifInBroadcastPkts + 374 dot12InNullAddressedFrames + 375 ifInErrors + 376 ifInDiscards + 377 ifInUnknownProtos - 378 dot12InHighPriorityFrames 380 dot12InNormPriorityOctets includes octets in unreadable frames, which 381 is not available elsewhere. The number of octets in unreadable 382 frames can be calculated as: 384 octetsInUnreadableFrames = dot12InNormPriorityOctets + 385 dot12InHighPriorityOctets - 386 ifInOctets 388 Also, the total bandwidth utilization by this interface can be 389 calculated as: 391 utilization = dot12InNormPriorityOctets + 392 dot12InHighPriorityOctets + 393 ifOutOctets 395 In other words, the normal priority receive counters were deemed 396 useful, whereas the normal priority transmit counters can be easily 397 calculated from other available counters. 399 3.7. Mapping of IEEE 802.12 Managed Objects 401 The following table lists all the managed objects defined for 402 oEndNode in the IEEE 802.12 Standard, and the corresponding SNMP 403 objects. 405 IEEE 802.12 Managed Object Corresponding SNMP Object 406 oEndNode 407 .aBroadcastFramesReceived IF-MIB - ifInBroadcastPkts 408 .aBroadcastFramesTransmitted IF-MIB - ifOutBroadcastPkts 409 .aDataErrorFramesReceived dot12InDataErrors 410 .aDesiredFramingType dot12DesiredFramingType 411 .aDesiredPromiscuousStatus dot12DesiredPromiscStatus 412 .aFramesTransmitted IF-MIB - ifOutUCastPkts + 413 ifOutMulticastPkts + 414 ifOutBroadcastPkts 415 .aFramingCapability dot12FramingCapability 416 .aFunctionalAddresses IF-MIB - ifRcvAddressTable 417 .aHighPriorityFramesReceived dot12InHighPriorityFrames 418 .aHighPriorityFramesTransmitted dot12OutHighPriorityFrames 419 .aHighPriorityOctetsReceived dot12InHighPriorityOctets or 420 dot12InHCHighPriorityOctets 421 .aHighPriorityOctetsTransmitted dot12OutHighPriorityOctets or 422 dot12OutHCHighPriorityOctets 423 .aIPMFramesReceived dot12InIPMErrors 424 .aLastTrainingConfig dot12LastTrainingConfig 425 .aMACID IF-MIB - ifIndex 426 .aMACStatus dot12Status 427 .aMACVersion dot12TrainingVersion 428 .aMediaType 429 Tranceiver MIB issue 430 .aMulticastFramesReceived IF-MIB - ifInMulticastPkts 431 .aMulticastFramesTransmitted IF-MIB - ifOutMulticastPkts 432 .aMulticastReceiveStatus IF-MIB - ifRcvAddressTable 433 .aNormalPriorityFramesReceived dot12InNormPriorityFrames 434 .aNormalPriorityOctetsReceived dot12InNormPriorityOctets or 435 dot12InHCNormPriorityOctets 436 .aNullAddressedFramesReceived dot12InNullAddressedFrames 437 .aOctetsTransmitted IF-MIB - ifOutOctets or 438 ifHCOutOctets 439 .aOversizeFramesReceived dot12InOversizeFrameErrors 440 .aReadableFramesReceived IF-MIB - ifInUcastPkts + 441 ifInMulticastPkts + 442 ifInBroadcastPkts 443 .aReadableOctetsReceived IF-MIB - ifInOctets or 444 ifHCInOctets 445 .aReadMulticastList IF-MIB - ifRcvAddressTable 446 .aReadWriteMACAddress IF-MIB - ifPhysAddress 447 .aTransitionsIntoTraining dot12TransitionIntoTrainings 448 .acAddGroupAddress IF-MIB - ifRcvAddressTable 449 .acClose dot12Commands: 'close' 450 .acDeleteGroupAddress IF-MIB - ifRcvAddressTable 451 .acExecuteSelftest IF-MIB - ifAdminStatus 452 .acInitializeMAC dot12Commands: 'reset' 453 .acOpen dot12Commands: 'open' 455 4. Definitions 457 DOT12-IF-MIB DEFINITIONS ::= BEGIN 459 IMPORTS 460 experimental, Counter32, Counter64, OBJECT-TYPE, 461 MODULE-IDENTITY 462 FROM SNMPv2-SMI 463 MODULE-COMPLIANCE, OBJECT-GROUP 464 FROM SNMPv2-CONF 465 ifIndex 466 FROM IF-MIB; 468 dot12MIB MODULE-IDENTITY 469 LAST-UPDATED "9510270146Z" 470 ORGANIZATION "IETF 100VG-AnyLAN MIB Working Group" 471 CONTACT-INFO 472 " John Flick 474 Postal: Hewlett Packard Company 475 8000 Foothills Blvd. M/S 5556 476 Roseville, CA 95747-5556 477 Tel: +1 916 785 4018 478 Fax: +1 916 785 3583 480 E-mail: johnf@hprnd.rose.hp.com" 481 DESCRIPTION 482 "This MIB module describes objects for 483 managing 100VG-AnyLAN interfaces." 484 ::= { experimental 63 } 485 -- move to { transmission 55 } 487 dot12MIBObjects OBJECT IDENTIFIER ::= { dot12MIB 1 } 489 dot12ConfigTable OBJECT-TYPE 490 SYNTAX SEQUENCE OF Dot12ConfigEntry 491 MAX-ACCESS not-accessible 492 STATUS current 493 DESCRIPTION 494 "Configuration information for a collection of 495 802.12 interfaces attached to a particular 496 system." 497 ::= { dot12MIBObjects 1 } 499 dot12ConfigEntry OBJECT-TYPE 500 SYNTAX Dot12ConfigEntry 501 MAX-ACCESS not-accessible 502 STATUS current 503 DESCRIPTION 504 "Configuration for a particular interface to an 505 802.12 medium." 506 INDEX { ifIndex } 507 ::= { dot12ConfigTable 1 } 509 Dot12ConfigEntry ::= 510 SEQUENCE { 511 dot12DesiredFramingType INTEGER, 512 dot12FramingCapability INTEGER, 513 dot12DesiredPromiscStatus INTEGER, 514 dot12TrainingVersion INTEGER, 515 dot12LastTrainingConfig OCTET STRING, 516 dot12Commands INTEGER, 517 dot12Status INTEGER, 518 dot12CurrentFramingType INTEGER, 519 dot12ControlMode INTEGER 520 } 522 dot12DesiredFramingType OBJECT-TYPE 523 SYNTAX INTEGER { 524 frameType88023(1), 525 frameType88025(2), 526 frameTypeEither(3) 527 } 528 MAX-ACCESS read-write 529 STATUS current 530 DESCRIPTION 531 "The type of framing which will be requested by 532 the interface during the next interface MAC 533 initialization or open action. 535 In master mode, this is the framing mode which 536 will be granted by the interface. Note that 537 for a master mode interface, this object must be 538 equal to 'frameType88023' or 'frameType88025', 539 since a master mode interface cannot grant 540 'frameTypeEither'." 541 REFERENCE 542 "IEEE 802.12, Layer Management, 13.2.5.2.1, 543 aDesiredFramingType." 544 ::= { dot12ConfigEntry 1 } 546 dot12FramingCapability OBJECT-TYPE 547 SYNTAX INTEGER { 548 frameType88023(1), 549 frameType88025(2), 550 frameTypeEither(3) 552 } 553 MAX-ACCESS read-only 554 STATUS current 555 DESCRIPTION 556 "The type of framing this interface is capable of 557 supporting." 558 REFERENCE 559 "IEEE 802.12, Layer Management, 13.2.5.2.1, 560 aFramingCapability." 561 ::= { dot12ConfigEntry 2 } 563 dot12DesiredPromiscStatus OBJECT-TYPE 564 SYNTAX INTEGER { 565 singleAddressMode(1), 566 promiscuousMode(2) 567 } 568 MAX-ACCESS read-write 569 STATUS current 570 DESCRIPTION 571 "This object is used to select the promiscuous 572 mode that this interface will request in the next 573 training packet issued on this interface. 574 Whether the repeater grants the requested mode 575 must be verified by examining the state of the PP 576 bits in the corresponding instance of 577 dot12LastTrainingConfig. 579 In master mode, this object controls whether or 580 not promiscuous mode will be granted by the 581 interface when requested by the lower level 582 device. 584 Note that this object indicates the desired mode 585 for the next time the interface trains. The 586 currently active mode will be reflected in 587 dot12LastTrainingConfig and in ifPromiscuousMode." 588 REFERENCE 589 "IEEE 802.12, Layer Management, 13.2.5.2.1, 590 aDesiredPromiscuousStatus." 591 ::= { dot12ConfigEntry 3 } 593 dot12TrainingVersion OBJECT-TYPE 594 SYNTAX INTEGER (0..7) 595 MAX-ACCESS read-only 596 STATUS current 597 DESCRIPTION 598 "The value that will be used in the version bits 599 (vvv bits) in training frames on this interface. 601 This is the highest version number supported by 602 this MAC." 603 REFERENCE 604 "IEEE 802.12, Layer Management, 13.2.5.2.1, 605 aMACVersion." 606 ::= { dot12ConfigEntry 4 } 608 dot12LastTrainingConfig OBJECT-TYPE 609 SYNTAX OCTET STRING (SIZE(2)) 610 MAX-ACCESS read-only 611 STATUS current 612 DESCRIPTION 613 "This 16 bit field contains the configuration 614 bits from the most recent error-free training 615 frame received during training on this interface. 616 Training request frames are received when in 617 master mode, while training response frames are 618 received in slave mode. 620 First Octet: Second Octet: 622 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 623 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 624 |v|v|v|D|C|N|0|0| |0|0|0|F|F|P|P|R| 625 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 627 vvv: The version of the 802.12 training 628 protocol with which the device at the 629 other end of the link is compliant 630 D: 0 = No duplicate address has been 631 detected. This bit is always zero 632 in training request frames. 633 1 = Duplicate address has been detected 634 C: 0 = The requested configuration is 635 compatible with the port. This bit 636 is always zero in training request 637 frames. 638 1 = The requested configuration is not 639 compatible with the port. 640 N: 0 = Access will be allowed, providing 641 the configuration is compatible (C 642 = 0). This bit is always zero in 643 training request frames. 644 1 = Access is not granted because of 645 security restrictions 646 FF: 00 = frameType88023 647 01 = frameType88025 648 10 = reserved 649 11 = frameTypeEither (this value is seen 650 only when in master mode) 651 PP: 00 = singleAddressMode 652 01 = promiscuousMode 653 10 = reserved 654 11 = reserved 655 R: 0 = Access as an end node 656 1 = Access as a repeater (this value is 657 seen only when in master mode and 658 the other end of the link connects 659 to a repeater) 661 Note that dot12Status must be examined to see if 662 any error-free training frames have been 663 received." 664 REFERENCE 665 "IEEE 802.12, Layer Management, 13.2.5.2.1, 666 aLastTrainingConfig." 667 ::= { dot12ConfigEntry 5 } 669 -- { dot12ConfigEntry 6 } is unassigned 671 dot12Commands OBJECT-TYPE 672 SYNTAX INTEGER { 673 noOp(1), 674 open(2), 675 reset(3), 676 close(4) 677 } 678 MAX-ACCESS read-write 679 STATUS current 680 DESCRIPTION 681 "If the current value of dot12Status is 'closed', 682 setting the value of this object to 'open' will 683 change the corresponding instance of MIB-II's 684 ifAdminStatus to 'up', cause this interface to 685 enter the 'opening' state, and will cause training 686 to be initiated on this interface. The progress 687 and success of the open is given by the values of 688 the dot12Status object. Setting this object to 689 'open' when dot12Status has a value other than 690 'closed' has no effect. 692 Setting the corresponding instance of ifAdminStatus 693 to 'up' when the current value of dot12Status is 694 'closed' will have the same effect as setting this 695 object to 'open'. Setting ifAdminStatus to 'up' 696 when dot12Status has a value other than 'closed' 697 has no effect. 699 Setting the value of this object to 'close' will 700 move this interface into the 'closed' state and 701 cause all transmit and receive actions to stop. 702 This object will then have to be set to 'open' in 703 order to reinitiate training. 705 Setting the corresponding instance of ifAdminStatus 706 to 'down' will have the same effect as setting this 707 object to 'close'. 709 Setting the value of this object to 'reset' when 710 the current value of dot12Status has a value other 711 than 'closed' will reset the interface. On a 712 reset, all MIB counters should retain their values. 713 This will cause the MAC to initiate an 714 acInitializeMAC action as specified in IEEE 802.12. 715 This will cause training to be reinitiated on this 716 interface. Setting this object to 'reset' when 717 dot12Status has a value of 'closed' has no effect. 718 Setting this object to 'reset' has no effect on the 719 corresponding instance of ifAdminStatus. 721 Setting the value of this object to 'noOp' has no 722 effect. 724 When read, this object will always have a value 725 of 'noOp'." 726 REFERENCE 727 "IEEE 802.12, Layer Management, 13.2.5.2.2, 728 acOpen, acClose, acInitializeMAC. 729 Also, RFC1231 IEEE802.5 Token Ring MIB, 730 dot5Commands." 731 ::= { dot12ConfigEntry 7 } 733 dot12Status OBJECT-TYPE 734 SYNTAX INTEGER { 735 opened(1), 736 closed(2), 737 opening(3), 738 openFailure(5), 739 linkFailure(6) 740 } 741 MAX-ACCESS read-only 742 STATUS current 743 DESCRIPTION 744 "The current interface status with respect to 745 training. One of the following values: 747 opened - Training has completed 748 successfully. 749 closed - MAC has been disabled by 750 setting dot12Commands to 751 'close'. 752 opening - MAC is in training. Training 753 signals have been received. 754 openFailure - Passed 24 error-free packets, 755 but there is a problem, noted 756 in the training configuration 757 bits (dot12LastTrainingConfig). 758 linkFailure - Training signals not received, 759 or could not pass 24 error-free 760 packets. 762 Whenever the dot12Commands object is set to 763 'close' or ifAdminStatus is set to 'down', the MAC 764 will go silent, dot12Status will be 'closed', and 765 ifOperStatus will be 'down'. 767 When the value of this object is equal to 'closed' 768 and the dot12Commands object is set to 'open' or 769 the ifAdminStatus object is set to 'up', training 770 will be initiated on this interface. When the 771 value of this object is not equal to 'closed' and 772 the dot12Commands object is set to 'reset', 773 training will be reinitiated on this interface. 774 Note that sets of some other objects (e.g. 775 dot12ControlMode) or external events (e.g. MAC 776 protocol violations) may also cause training to be 777 reinitiated on this interface. 779 When training is initiated or reinitiated on an 780 interface, the end node will send Training_Up to 781 the master and initially go to the 'linkFailure' 782 state and ifOperStatus will go to 'down'. 783 When the master sends back Training_Down, 784 dot12Status will change to the 'opening' state, 785 ifOperStatus will change to 'testing', and training 786 packets will be transferred. 788 After all of the training packets have been 789 passed, dot12Status will change to 'linkFailure' 790 if 24 consecutive error-free packets were not 791 passed, 'opened' if 24 consecutive error-free 792 packets were passed and the training 793 configuration bits were OK, or 'openFailure' if 794 there were 24 consecutive error-free packets, but 795 there was a problem with the training 796 configuration bits. 798 When in the 'openFailure' state, the 799 dot12LastTrainingConfig object will contain the 800 configuration bits from the last training 801 packet which can be examined to determine the 802 exact reason for the training configuration 803 failure. 805 If training did not succeed (dot12Status is 806 'linkFailure' or 'openFailure), the entire 807 process will be restarted after 808 MAC_Retraining_Delay_Timer seconds. 810 If training does succeed (dot12Status changes to 811 'opened'), ifOperStatus will change to 'up'. If 812 training does not succeed (dot12Status changes to 813 'linkFailure' or 'openFailure'), ifOperStatus will 814 change to 'down'." 815 REFERENCE 816 "IEEE 802.12, Layer Management, 13.2.5.2.1, 817 aMACStatus." 818 ::= { dot12ConfigEntry 8 } 820 dot12CurrentFramingType OBJECT-TYPE 821 SYNTAX INTEGER { 822 frameType88023(1), 823 frameType88025(2), 824 frameTypeUnknown(3) 825 } 826 MAX-ACCESS read-only 827 STATUS current 828 DESCRIPTION 829 "When dot12DesiredFramingType is one of 830 'frameType88023' or 'frameType88025', this is the 831 type of framing asserted by the interface. 833 When dot12DesiredFramingType is 'frameTypeEither', 834 dot12CurrentFramingType shall be one of 835 'frameType88023' or 'frameType88025' when the 836 dot12Status is 'opened'. When the dot12Status is 837 anything other than 'opened', 838 dot12CurrentFramingType shall take the value of 839 'frameTypeUnknown'." 840 ::= { dot12ConfigEntry 9 } 842 dot12ControlMode OBJECT-TYPE 843 SYNTAX INTEGER { 844 masterMode(1), 845 slaveMode(2), 846 learn(3) 847 } 848 MAX-ACCESS read-write 849 STATUS current 850 DESCRIPTION 851 "This object is used to configure and report 852 whether or not this interface is operating in 853 master mode. In a Demand Priority network, end 854 node interfaces typically operate in slave mode, 855 while switch interfaces may control the Demand 856 Priority protocol and operate in master mode. 858 This object may be implemented as a read-only 859 object by those agents and interfaces that do not 860 implement software control of master mode. In 861 particular, interfaces that cannot operate in 862 master mode, and interfaces on which master mode 863 is controlled by a pushbutton on the device, 864 should implement this object read-only. 866 Some interfaces do not require network management 867 configuration of this feature and can autosense 868 whether to use master mode or slave mode. The 869 value 'learn' is used for that purpose. While 870 autosense is taking place, the value 'learn' is 871 returned. 873 A network management operation which modifies the 874 value of dot12ControlMode causes the interface 875 to retrain." 876 ::= { dot12ConfigEntry 10 } 878 dot12StatTable OBJECT-TYPE 879 SYNTAX SEQUENCE OF Dot12StatEntry 880 MAX-ACCESS not-accessible 881 STATUS current 882 DESCRIPTION 883 "Statistics for a collection of 802.12 interfaces 884 attached to a particular system." 885 ::= { dot12MIBObjects 2 } 887 dot12StatEntry OBJECT-TYPE 888 SYNTAX Dot12StatEntry 889 MAX-ACCESS not-accessible 890 STATUS current 891 DESCRIPTION 892 "Statistics for a particular interface to an 893 802.12 medium. The receive statistics in this 894 table apply only to packets received by this 895 station (i.e., packets whose destination address 896 is either the local station address, the 897 broadcast address, or a multicast address that 898 this station is receiving, unless the station is 899 in promiscuous mode)." 900 INDEX { ifIndex } 901 ::= { dot12StatTable 1 } 903 Dot12StatEntry ::= 904 SEQUENCE { 905 dot12InHighPriorityFrames Counter32, 906 dot12InHighPriorityOctets Counter32, 907 dot12InNormPriorityFrames Counter32, 908 dot12InNormPriorityOctets Counter32, 909 dot12InIPMErrors Counter32, 910 dot12InOversizeFrameErrors Counter32, 911 dot12InDataErrors Counter32, 912 dot12InNullAddressedFrames Counter32, 913 dot12OutHighPriorityFrames Counter32, 914 dot12OutHighPriorityOctets Counter32, 915 dot12TransitionIntoTrainings Counter32, 916 dot12HCInHighPriorityOctets Counter64, 917 dot12HCInNormPriorityOctets Counter64, 918 dot12HCOutHighPriorityOctets Counter64 919 } 921 dot12InHighPriorityFrames OBJECT-TYPE 922 SYNTAX Counter32 923 MAX-ACCESS read-only 924 STATUS current 925 DESCRIPTION 926 "This object is a count of high priority frames 927 that have been received on this interface. 928 Includes both good and bad high priority frames, 929 as well as high priority training frames. Does 930 not include normal priority frames which were 931 priority promoted." 932 REFERENCE 933 "IEEE 802.12, Layer Management, 13.2.5.2.1, 934 aHighPriorityFramesReceived." 935 ::= { dot12StatEntry 1 } 937 dot12InHighPriorityOctets OBJECT-TYPE 938 SYNTAX Counter32 939 MAX-ACCESS read-only 940 STATUS current 941 DESCRIPTION 942 "This object is a count of the number of octets 943 contained in high priority frames that have been 944 received on this interface. This counter is 945 incremented by OctetCount for each frame received 946 on this interface which is counted by 947 dot12InHighPriorityFrames. 949 Note that this counter will roll over very 950 quickly. It is provided for backward 951 compatibility for Network Management protocols 952 that do not support 64 bit counters (e.g. SNMP 953 version 1)." 954 REFERENCE 955 "IEEE 802.12, Layer Management, 13.2.5.2.1, 956 aHighPriorityOctetsReceived." 957 ::= { dot12StatEntry 2 } 959 dot12InNormPriorityFrames OBJECT-TYPE 960 SYNTAX Counter32 961 MAX-ACCESS read-only 962 STATUS current 963 DESCRIPTION 964 "This object is a count of normal priority frames 965 that have been received on this interface. 966 Includes both good and bad normal priority 967 frames, as well as normal priority training 968 frames and normal priority frames which were 969 priority promoted." 970 REFERENCE 971 "IEEE 802.12, Layer Management, 13.2.5.2.1, 972 aNormalPriorityFramesReceived." 973 ::= { dot12StatEntry 3 } 975 dot12InNormPriorityOctets OBJECT-TYPE 976 SYNTAX Counter32 977 MAX-ACCESS read-only 978 STATUS current 979 DESCRIPTION 980 "This object is a count of the number of octets 981 contained in normal priority frames that have 982 been received on this interface. This counter is 983 incremented by OctetCount for each frame received 984 on this interface which is counted by 985 dot12InNormPriorityFrames. 987 Note that this counter will roll over very 988 quickly. It is provided for backward 989 compatibility for Network Management protocols 990 that do not support 64 bit counters (e.g. SNMP 991 version 1)." 992 REFERENCE 993 "IEEE 802.12, Layer Management, 13.2.5.2.1, 994 aNormalPriorityOctetsReceived." 995 ::= { dot12StatEntry 4 } 997 dot12InIPMErrors OBJECT-TYPE 998 SYNTAX Counter32 999 MAX-ACCESS read-only 1000 STATUS current 1001 DESCRIPTION 1002 "This object is a count of the number of frames 1003 that have been received on this interface with an 1004 invalid packet marker and no PMI errors. A 1005 repeater will write an invalid packet marker to 1006 the end of a frame containing errors as it is 1007 forwarded through the repeater to the other 1008 ports. This counter is incremented by one for 1009 each frame received on this interface which has 1010 had an invalid packet marker added to the end of 1011 the frame." 1012 REFERENCE 1013 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1014 aIPMFramesReceived." 1015 ::= { dot12StatEntry 5 } 1017 dot12InOversizeFrameErrors OBJECT-TYPE 1018 SYNTAX Counter32 1019 MAX-ACCESS read-only 1020 STATUS current 1021 DESCRIPTION 1022 "This object is a count of oversize frames 1023 received on this interface. This counter is 1024 incremented by one for each frame received on 1025 this interface whose OctetCount is larger than 1026 the maximum legal frame size. The frame size 1027 which causes this counter to increment is 1028 dependent on the current framing type." 1029 REFERENCE 1030 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1031 aOversizeFramesReceived." 1032 ::= { dot12StatEntry 6 } 1034 dot12InDataErrors OBJECT-TYPE 1035 SYNTAX Counter32 1036 MAX-ACCESS read-only 1037 STATUS current 1038 DESCRIPTION 1039 "This object is a count of errored frames 1040 received on this interface. This counter is 1041 incremented by one for each frame received on 1042 this interface with any of the following errors: 1043 bad FCS (with no IPM), PMI errors (excluding 1044 frames with an IPM as the only PMI error), 1045 undersize, bad start of frame delimiter, or bad 1046 end of packet marker. Does not include frames 1047 counted by dot12InIPMErrors, 1048 dot12InNullAddressedFrames, or 1049 dot12InOversizeFrameErrors. 1051 This counter indicates problems with the cable 1052 directly attached to this interface, while 1053 dot12InIPMErrors indicates problems with remote 1054 cables." 1055 REFERENCE 1056 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1057 aDataErrorFramesReceived." 1058 ::= { dot12StatEntry 7 } 1060 dot12InNullAddressedFrames OBJECT-TYPE 1061 SYNTAX Counter32 1062 MAX-ACCESS read-only 1063 STATUS current 1064 DESCRIPTION 1065 "This object is a count of null addressed frames 1066 received on this interface. This counter is 1067 incremented by one for each frame received on 1068 this interface with a destination MAC address 1069 consisting of all zero bits. Both void and 1070 training frames are included in this counter. 1072 Note that since this station would normally not 1073 receive null addressed frames, this counter is 1074 only incremented when this station is operating 1075 in promiscuous mode." 1076 REFERENCE 1077 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1078 aNullAddressedFramesReceived." 1079 ::= { dot12StatEntry 8 } 1081 dot12OutHighPriorityFrames OBJECT-TYPE 1082 SYNTAX Counter32 1083 MAX-ACCESS read-only 1084 STATUS current 1085 DESCRIPTION 1086 "This counter is incremented by one for each high 1087 priority frame successfully transmitted out this 1088 interface." 1089 REFERENCE 1090 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1091 aHighPriorityFramesTransmitted." 1092 ::= { dot12StatEntry 9 } 1094 dot12OutHighPriorityOctets OBJECT-TYPE 1095 SYNTAX Counter32 1096 MAX-ACCESS read-only 1097 STATUS current 1098 DESCRIPTION 1099 "This counter is incremented by OctetCount for 1100 each frame counted by dot12OutHighPriorityFrames. 1102 Note that this counter will roll over very 1103 quickly. It is provided for backward 1104 compatibility for Network Management protocols 1105 that do not support 64 bit counters (e.g. SNMP 1106 version 1)." 1107 REFERENCE 1108 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1109 aHighPriorityOctetsTransmitted." 1110 ::= { dot12StatEntry 10 } 1112 dot12TransitionIntoTrainings OBJECT-TYPE 1113 SYNTAX Counter32 1114 MAX-ACCESS read-only 1115 STATUS current 1116 DESCRIPTION 1117 "This object is a count of the number of times 1118 this interface has entered the training state. 1119 This counter is incremented by one each time 1120 dot12Status transitions to 'linkFailure' from any 1121 state other than 'opening' or 'openFailure'." 1122 REFERENCE 1123 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1124 aTransitionsIntoTraining." 1125 ::= { dot12StatEntry 11 } 1127 dot12HCInHighPriorityOctets OBJECT-TYPE 1128 SYNTAX Counter64 1129 MAX-ACCESS read-only 1130 STATUS current 1131 DESCRIPTION 1132 "This object is a count of the number of octets 1133 contained in high priority frames that have been 1134 received on this interface. This counter is 1135 incremented by OctetCount for each frame received 1136 on this interface which is counted by 1137 dot12InHighPriorityFrames. 1139 This counter is a 64 bit version of 1140 dot12InHighPriorityOctets. It should be used by 1141 Network Management protocols which support 64 bit 1142 counters (e.g. SNMPv2)." 1143 REFERENCE 1144 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1145 aHighPriorityOctetsReceived." 1146 ::= { dot12StatEntry 12 } 1148 dot12HCInNormPriorityOctets OBJECT-TYPE 1149 SYNTAX Counter64 1150 MAX-ACCESS read-only 1151 STATUS current 1152 DESCRIPTION 1153 "This object is a count of the number of octets 1154 contained in normal priority frames that have 1155 been received on this interface. This counter is 1156 incremented by OctetCount for each frame received 1157 on this interface which is counted by 1158 dot12InNormPriorityFrames. 1160 This counter is a 64 bit version of 1161 dot12InNormPriorityOctets. It should be used by 1162 Network Management protocols which support 64 bit 1163 counters (e.g. SNMPv2)." 1164 REFERENCE 1165 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1166 aNormalPriorityOctetsReceived." 1167 ::= { dot12StatEntry 13 } 1169 dot12HCOutHighPriorityOctets OBJECT-TYPE 1170 SYNTAX Counter64 1171 MAX-ACCESS read-only 1172 STATUS current 1173 DESCRIPTION 1174 "This counter is incremented by OctetCount for 1175 each frame counted by dot12OutHighPriorityFrames. 1177 This counter is a 64 bit version of 1178 dot12OutHighPriorityOctets. It should be used by 1179 Network Management protocols which support 64 bit 1180 counters (e.g. SNMPv2)." 1181 REFERENCE 1182 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1183 aHighPriorityOctetsTransmitted." 1184 ::= { dot12StatEntry 14 } 1186 -- conformance information 1188 dot12Conformance OBJECT IDENTIFIER ::= { dot12MIB 2 } 1190 dot12Compliances OBJECT IDENTIFIER ::= { dot12Conformance 1 } 1191 dot12Groups OBJECT IDENTIFIER ::= { dot12Conformance 2 } 1193 -- compliance statements 1195 dot12Compliance MODULE-COMPLIANCE 1196 STATUS current 1197 DESCRIPTION 1198 "The compliance statement for managed network 1199 entities that have 802.12 interfaces." 1201 MODULE -- this module 1202 MANDATORY-GROUPS { dot12ConfigGroup, dot12StatsGroup } 1204 OBJECT dot12DesiredFramingType 1205 MIN-ACCESS read-only 1206 DESCRIPTION 1207 "Write access to this object is not required." 1209 OBJECT dot12DesiredPromiscStatus 1210 MIN-ACCESS read-only 1211 DESCRIPTION 1212 "Write access to this object is not required." 1214 OBJECT dot12Commands 1215 MIN-ACCESS read-only 1216 DESCRIPTION 1217 "Write access to this object is not required." 1219 OBJECT dot12ControlMode 1220 MIN-ACCESS read-only 1221 DESCRIPTION 1222 "Write access to this object is not required." 1223 ::= { dot12Compliances 1 } 1225 -- units of conformance 1226 dot12ConfigGroup OBJECT-GROUP 1227 OBJECTS { dot12DesiredFramingType, 1228 dot12FramingCapability, 1229 dot12DesiredPromiscStatus, 1230 dot12TrainingVersion, 1231 dot12LastTrainingConfig, 1232 dot12Commands, dot12Status, 1233 dot12CurrentFramingType, 1234 dot12ControlMode } 1235 STATUS current 1236 DESCRIPTION 1237 "A collection of objects for managing the status 1238 and configuration of IEEE 802.12 interfaces." 1239 ::= { dot12Groups 1 } 1241 dot12StatsGroup OBJECT-GROUP 1242 OBJECTS { dot12InHighPriorityFrames, 1243 dot12InHighPriorityOctets, 1244 dot12InNormPriorityFrames, 1245 dot12InNormPriorityOctets, 1246 dot12InIPMErrors, 1247 dot12InOversizeFrameErrors, 1248 dot12InDataErrors, 1249 dot12InNullAddressedFrames, 1250 dot12OutHighPriorityFrames, 1251 dot12OutHighPriorityOctets, 1252 dot12TransitionIntoTrainings, 1253 dot12HCInHighPriorityOctets, 1254 dot12HCInNormPriorityOctets, 1255 dot12HCOutHighPriorityOctets } 1256 STATUS current 1257 DESCRIPTION 1258 "A collection of objects providing statistics for 1259 IEEE 802.12 interfaces." 1260 ::= { dot12Groups 2 } 1262 END 1264 5. Acknowledgements 1266 This document was produced by the IETF 100VG-AnyLAN Working Group. 1267 It is based on the work of IEEE 802.12. 1269 6. References 1271 [1] Information processing systems - Open Systems Interconnection - 1272 Specification of Abstract Syntax Notation One (ASN.1), 1273 International Organization for Standardization. International 1274 Standard 8824 (December, 1987). 1276 [2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1277 of Management Information for version 2 of the Simple Network 1278 Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., 1279 Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1280 University, April 1993. 1282 [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1283 Conventions for version 2 of the Simple Network Management 1284 Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN 1285 Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1286 University, April 1993. 1288 [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1289 "Conformance Statements for version 2 of the Simple Network 1290 Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., 1291 Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1292 University, April 1993. 1294 [5] McCloghrie, K., and M. Rose, "Management Information Base for 1295 Network Management of TCP/IP-based internets - MIB-II", STD 17, 1296 RFC 1213, Hughes LAN Systems, Performance Systems International, 1297 March 1991. 1299 [6] IEEE, "Demand Priority Access Method, Physical Layer and Repeater 1300 Specifications for 100 Mb/s Operation", IEEE Standard 802.12" 1302 [7] McCloghrie, K., and Kastenholz, F., "Evolution of the Interfaces 1303 Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, 1304 January 1994. 1306 [8] McCloghrie, K., Baker, F., and Decker, E., "IEEE 802.5 Station 1307 Source Routing MIB using SMIv2", RFC 1749, cisco Systems, Inc., 1308 December, 1994. 1310 7. Security Considerations 1312 Security issues are not discussed in this memo. 1314 8. Author's Address 1316 John Flick 1317 Hewlett Packard Company 1318 8000 Foothills Blvd. M/S 5556 1319 Roseville, CA 95747-5556 1321 Phone: +1 916 785 4018 1322 Email: johnf@hprnd.rose.hp.com 1324 Table of Contents 1326 1. Abstract ................................................... 2 1327 2. Object Definitions ......................................... 2 1328 3. Overview ................................................... 2 1329 3.1. MAC Addresses ............................................ 3 1330 3.2. Relation to RFC 1213 ..................................... 3 1331 3.3. Relation to RFC 1573 ..................................... 3 1332 3.3.1. Layering Model ......................................... 4 1333 3.3.2. Virtual Circuits ....................................... 4 1334 3.3.3. ifTestTable ............................................ 4 1335 3.3.4. ifRcvAddressTable ...................................... 4 1336 3.3.5. ifPhysAddress .......................................... 4 1337 3.3.6. Specific Interface MIB Objects ......................... 5 1338 3.4. Relation to RFC 1749 ..................................... 8 1339 3.5. Master Mode Operation .................................... 8 1340 3.6. Normal and High Priority Counters ........................ 8 1341 3.7. Mapping of IEEE 802.12 Managed Objects ................... 9 1342 4. Definitions ................................................ 11 1343 5. Acknowledgements ........................................... 27 1344 6. References ................................................. 27 1345 7. Security Considerations .................................... 28 1346 8. Author's Address ........................................... 28