Internet Draft IEEE 802.12 Interface MIB September 8 1995 Definitions of Managed Objects for IEEE 802.12 Interfaces September 8, 1995 John Flick Hewlett Packard Company 8000 Foothills Blvd. M/S 5556 Roseville, CA 95747-5556 johnf@hprnd.rose.hp.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). John Flick Expires March 8, 1995 [Page 1] Internet Draft IEEE 802.12 Interface MIB September 8 1995 1. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network interfaces based on IEEE 802.12. This memo does not specify a standard for the Internet community. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. 3. Overview Instances of these object types represent attributes of an interface to a 100VG-AnyLAN communications medium. At present, 100VG-AnyLAN John Flick Expires March 8, 1995 [Page 2] Internet Draft IEEE 802.12 Interface MIB September 8 1995 media are identified by one value of the ifType object in the Internet-standard MIB: ieee80212(55) For this interface, the value of the ifSpecific variable in the MIB- II [4] has the OBJECT IDENTIFIER value: dot12MIB OBJECT IDENTIFIER ::= { experimental 63 } The definitions presented here are based on the IEEE Standard802.12, [6] Clause 13 "Layer Management Functions And Services", and Annex E "GDMO Specifications for Demand Priority Managed Objects". Implementors of these MIB objects should note that the IEEE document explicitly describes (in the form of Pascal pseudocode) when, where, and how various MAC attributes are measured. The IEEE document also describes the effects of MAC actions that may be invoked by manipulating instances of the MIB objects defined here. To the extent that some of the attributes defined in [6] are represented by previously defined objects in the Internet-standard MIB or in the Evolution of the Interfaces Group of MIB-II [7], such attributes are not redundantly represented by objects defined in this memo. Among the attributes represented by objects defined in other memos are the number of octets transmitted or received on a particular interface, the MAC address of an interface, and multicast information associated with an interface. 3.1. MAC Addresses All representations of MAC addresses in this MIB module, and in other related MIB modules (like RFC 1573), are in "canonical" order defined by 802.1a, i.e., as if it were transmitted least significant bit first. This is true even if the interface is operating in token ring framing mode, which requires MAC addresses to be transmitted most significant bit first. 3.2. Relation to RFC 1213 This section applies only when this MIB is used in conjunction with the "old" (i.e., pre-RFC 1573) interface group. The relationship between a 100VG-AnyLAN interface and an interface in the context of the Internet-standard MIB is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. John Flick Expires March 8, 1995 [Page 3] Internet Draft IEEE 802.12 Interface MIB September 8 1995 3.3. Relation to RFC 1573 RFC 1573, the Interface MIB Evolution, requires that any MIB which is an adjunct of the Interface MIB, clarify specific areas within the Interface MIB. These areas are intentionally left vague in RFC 1573 to avoid over constraining the MIB, thereby precluding management of certain media-types. Section 3.3 of RFC 1573 enumerates several areas which a media- specific MIB must clarify. In addition, there are some objects in RFC 1573 for which additional clarification of how to apply them to a 100VG-AnyLAN interface woule be helpful. Each of these areas is addressed in a following subsection. The implementor is referred to RFC 1573 in order to understand the general intent of these areas. 3.3.1. Layering Model This MIB does not provide for layering. There are no sublayers. 3.3.2. Virtual Circuits This medium does not support virtual circuits and this area is not applicable to this MIB. 3.3.3. ifTestTable This MIB does not define any tests for media instrumented by this MIB. Implementation of the ifTestTable is not required. 3.3.4. ifRcvAddressTable This table contains all IEEE addresses, unicast, multicast, and broadcast, for which this interface will receive packets and forward them up to a higher layer entity for consumption. In addition, when the interface is using 802.5 framing mode, the ifRcvAddressTable will contain the functional address mask. In the event that the interface is part of a MAC bridge, this table does not include unicast addresses which are accepted for possible forwarding out some other port. This table is explicitly not intended to provide a bridge address filtering mechanism. 3.3.5. ifPhysAddress John Flick Expires March 8, 1995 [Page 4] Internet Draft IEEE 802.12 Interface MIB September 8 1995 This object contains the IEEE 802.12 address which is placed in the source-address field of any frames that originate at this interface. Usually this will be kept in ROM on the interface hardware. Some systems may set this address via software. In a system where there are several such addresses the designer has a tougher choice. The address chosen should be the one most likely to be of use to network management (e.g. the address placed in ARP responses for systems which are primarily IP systems). If the designer truly can not choose, use of the factory-provided ROM address is suggested. If the address can not be determined, an octet string of zero length should be returned. The address is stored in binary in this object. The address is stored in "canonical" bit order, that is, the Group Bit is positioned as the low-order bit of the first octet. Thus, the first byte of a multicast address would have the bit 0x01 set. This is true even when the interface is using token ring framing mode, which transmits addresses high-order bit first. 3.3.6. ifType This MIB applies to interfaces which have the following ifType value: ieee80212(55) 3.3.7. ifMtu The value of ifMtu on a 100VG-AnyLAN interface will depend on the type of framing that is in use on that interface. Changing the dot12DesiredFramingType may have the effect of changing ifMtu after the next time that the interface trains. 3.3.8. ifInErrors On a 100VG-AnyLAN interface, ifInErrors will be the sum of dot12InIPMErrors, dot12InOversizeFrameErrors, dot12InDataErrors, and any additional internal errors that may occur in an implementation. 3.3.9. ifOutErrors John Flick Expires March 8, 1995 [Page 5] Internet Draft IEEE 802.12 Interface MIB September 8 1995 On a 100VG-AnyLAN interface, ifOutErrors will be equal to the number of implementation-specific internal transmit errors on this interface. 3.3.10. ifPromiscuousMode ifPromiscuousMode reflects whether the interface has successfully trained and is currently operating in promiscuous mode. dot12DesiredPromiscStatus is used to select the promiscuous mode to be requested in the next training attempt. Setting ifPromiscuousMode will update dot12DesiredPromiscStatus and cause the interface to attempt to retrain using the new promiscuous mode. After the interface has retrained, ifPromiscuousMode will reflect the mode that is in use, not the mode that was requested. 3.4. Relation to RFC 1749 When an IEEE 802.12 interface is operating in token ring framing mode, and the end node supports token ring source routing, the agent should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB [9] for those interfaces. 3.5. Master Mode Operation In a 100VG-AnyLAN network, "master" devices act as network controllers to decide when to grant requesting end-nodes permission to transmit. These master devices may be repeaters, or other active controller devices such as switches. Devices which do not act as network controllers, such as end-nodes or passive switches, are considered to be operating in "slave" mode. The dot12ControlMode object indicates if the interfaces is operating in master mode or slave mode. 3.6. Normal and High Priority Counters The 100VG-AnyLAN interface MIB does not provide normal priority transmit counters. Standardization of normal priority transmit counters could not be justified -- ifOutUcastPkts, ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets, dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets should suffice. Since 100VG-AnyLAN uses point-to-point links, this information is available at the repeater end of the link if needed. John Flick Expires March 8, 1995 [Page 6] Internet Draft IEEE 802.12 Interface MIB September 8 1995 dot12InNormPriorityOctets includes octets of unreadable frames and can be combined with dot12InHighPriorityOctets and ifOutOctets to accurately calculate network utilization. 3.7. Mapping of IEEE 802.12 Managed Objects IEEE 802.12 Managed Object Corresponding SNMP Object oEndNode .aBroadcastFramesReceived IF-MIB - ifInBroadcastPkts .aBroadcastFramesTransmitted IF-MIB - ifOutBroadcastPkts .aDataErrorFramesReceived dot12InDataErrors .aDesiredFramingType dot12DesiredFramingType .aDesiredPromiscuousStatus dot12DesiredPromiscStatus .aFramesTransmitted IF-MIB - ifOutUCastPkts + ifOutMulticastPkts + ifOutBroadcastPkts .aFramingCapability dot12FramingCapability .aFunctionalAddresses IF-MIB - ifRcvAddressTable .aHighPriorityFramesReceived dot12InHighPriorityFrames .aHighPriorityFramesTransmitted dot12OutHighPriorityFrames .aHighPriorityOctetsReceived dot12InHighPriorityOctets dot12InHCHighPriorityOctets .aHighPriorityOctetsTransmitted dot12OutHighPriorityOctets dot12OutHCHighPriorityOctets .aIPMFramesReceived dot12InIPMErrors .aLastTrainingConfig dot12LastTrainingConfig .aMACID IF-MIB - ifIndex .aMACStatus dot12Status .aMACVersion dot12TrainingVersion .aMediaType dot12PMDType .aMulticastFramesReceived IF-MIB - ifInMulticastPkts .aMulticastFramesTransmitted IF-MIB - ifOutMulticastPkts .aMulticastReceiveStatus IF-MIB - ifRcvAddressTable .aNormalPriorityFramesReceived dot12InNormPriorityFrames .aNormalPriorityOctetsReceived dot12InNormPriorityOctets dot12InHCNormPriorityOctets .aNullAddressedFramesReceived dot12InNullAddressedFrames .aOctetsTransmitted IF-MIB - ifOutOctets ifHCOutOctets .aOversizeFramesReceived dot12InOversizeFrameErrors .aReadableFramesReceived IF-MIB - ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts .aReadableOctetsReceived IF-MIB - ifInOctets ifHCInOctets .aReadMulticastList IF-MIB - ifRcvAddressTable John Flick Expires March 8, 1995 [Page 7] Internet Draft IEEE 802.12 Interface MIB September 8 1995 .aReadWriteMACAddress IF-MIB - ifPhysAddress .aTransitionsIntoTraining dot12TransitionIntoTrainings .acAddGroupAddress IF-MIB - ifRcvAddressTable .acClose dot12Commands: 'close' .acDeleteGroupAddress IF-MIB - ifRcvAddressTable .acExecuteSelftest IF-MIB - ifAdminStatus .acInitializeMAC dot12Commands: 'reset' .acOpen dot12Commands: 'open' John Flick Expires March 8, 1995 [Page 8] Internet Draft IEEE 802.12 Interface MIB September 8 1995 4. Definitions DOT12-IF-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, Counter32, Counter64, OBJECT-TYPE, MODULE-IDENTITY, OBJECT-IDENTITY FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB; dot12MIB MODULE-IDENTITY LAST-UPDATED "9509070007Z" ORGANIZATION "Hewlett Packard Company, Roseville Networks Division" CONTACT-INFO " John Flick Postal: Hewlett Packard Company 8000 Foothills Blvd. M/S 5556 Roseville, CA 95747-5556 Tel: +1 916 785 4018 Fax: +1 916 785 3583 E-mail: johnf@hprnd.rose.hp.com" DESCRIPTION "This MIB module describes objects for managing 100VG-AnyLAN interfaces." ::= { experimental 63 } -- move to { transmission 55 } dot12MIBObjects OBJECT IDENTIFIER ::= { dot12MIB 1 } -- object identifiers for tranceiver types -- See dot12PMDType and vgRptrPMDType in the 802.12 Repeater -- MIB for usage. dot12XcvrTypes OBJECT IDENTIFIER ::= { dot12MIB 3 } dot12XcvrTypeUTP4 OBJECT-IDENTITY STATUS current DESCRIPTION "Object identifier for a 4-pair unshielded twisted pair 802.12 tranceiver" ::= { dot12XcvrTypes 1 } John Flick Expires March 8, 1995 [Page 9] Internet Draft IEEE 802.12 Interface MIB September 8 1995 dot12XcvrTypeSTP2 OBJECT-IDENTITY STATUS current DESCRIPTION "Object identifier for a 2-pair shielded twisted pair 802.12 tranceiver." ::= { dot12XcvrTypes 2 } dot12XcvrTypeFibre OBJECT-IDENTITY STATUS current DESCRIPTION "Object identifier for a 802.12 fibre optic tranceiver." ::= { dot12XcvrTypes 3 } dot12ConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot12ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration information for a collection of 802.12 interfaces attached to a particular system." ::= { dot12MIBObjects 1 } dot12ConfigEntry OBJECT-TYPE SYNTAX Dot12ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration for a particular interface to an 802.12 medium." INDEX { ifIndex } ::= { dot12ConfigTable 1 } Dot12ConfigEntry ::= SEQUENCE { dot12DesiredFramingType INTEGER, dot12FramingCapability INTEGER, dot12DesiredPromiscStatus INTEGER, dot12TrainingVersion INTEGER, dot12LastTrainingConfig OCTET STRING, dot12Commands INTEGER, dot12Status INTEGER, dot12CurrentFramingType INTEGER, dot12ControlMode INTEGER } John Flick Expires March 8, 1995 [Page 10] Internet Draft IEEE 802.12 Interface MIB September 8 1995 dot12DesiredFramingType OBJECT-TYPE SYNTAX INTEGER { frameType88023(1), frameType88025(2), frameTypeEither(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of framing which will be requested by the interface during the next interface MAC initialization or open action. In master mode, this is the framing mode which will be granted by the interfaces. Note that for master mode interfaces, this object must be equal to 'frameType88023' or 'frameType88025', since a master mode interface cannot grant 'frameTypeEither'." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aDesiredFramingType." ::= { dot12ConfigEntry 1 } dot12FramingCapability OBJECT-TYPE SYNTAX INTEGER { frameType88023(1), frameType88025(2), frameTypeEither(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of framing this interface is capable of supporting." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aFramingCapability." ::= { dot12ConfigEntry 2 } dot12DesiredPromiscStatus OBJECT-TYPE SYNTAX INTEGER { singleAddressMode(1), promiscuousMode(2) } MAX-ACCESS read-write STATUS current DESCRIPTION John Flick Expires March 8, 1995 [Page 11] Internet Draft IEEE 802.12 Interface MIB September 8 1995 "This object is used to select the promiscuous mode that this interface will request in the next training packet issued on this interface. Whether the repeater grants the requested mode must be verified by examining the state of the PP bits in the corresponding instance of dot12LastTrainingConfig. In master mode, this object controls whether or not promiscuous mode will be granted by the interface when requested by the lower level device. Note that this object indicates the desired mode for the next time the interface trains. The currently active mode will be reflected in dot12LastTrainingConfig and in ifPromiscuousMode." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aDesiredPromiscuousStatus." ::= { dot12ConfigEntry 3 } dot12TrainingVersion OBJECT-TYPE SYNTAX INTEGER (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "The value that will be used in the version bits (vvv bits) in training frames on this interface. This is the highest version number supported by this MAC." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aMACVersion." ::= { dot12ConfigEntry 4 } dot12LastTrainingConfig OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-only STATUS current DESCRIPTION "This 16 bit field contains the configuration bits from the most recent error-free training frame received during training on this interface. Training request frames are received when in master mode, while training response frames are received in slave mode. John Flick Expires March 8, 1995 [Page 12] Internet Draft IEEE 802.12 Interface MIB September 8 1995 First Octet: Second Octet: 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |v|v|v|D|C|N|0|0| |0|0|0|F|F|P|P|R| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ vvv: The version of the 802.12 training protocol with which the device at the other end of the link is compliant D: 0 = No duplicate address has been detected. This bit is always zero in training request frames. 1 = Duplicate address has been detected C: 0 = The requested configuration is compatible with the port. This bit is always zero in training request frames. 1 = The requested configuration is not compatible with the port. N: 0 = Access will be allowed, providing the configuration is compatible (C = 0). This bit is always zero in training request frames. 1 = Access is not granted because of security restrictions FF: 00 = frameType88023 01 = frameType88025 10 = reserved 11 = frameTypeEither (this value is seen only when in master mode) PP: 00 = singleAddressMode 01 = promiscuousMode 10 = reserved 11 = reserved R: 0 = Access as an end node 1 = Access as a repeater (this value is seen only when in master mode and the other end of the link connects to a repeater) Note that dot12Status must be examined to see if any error-free training frames have been received." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aLastTrainingConfig." ::= { dot12ConfigEntry 5 } John Flick Expires March 8, 1995 [Page 13] Internet Draft IEEE 802.12 Interface MIB September 8 1995 -- { dot12ConfigEntry 6 } is unassigned dot12Commands OBJECT-TYPE SYNTAX INTEGER { noOp(1), open(2), reset(3), close(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "If the current value of dot12Status is 'closed', setting the value of this object to 'open' will cause this interface to enter the 'opening' state, and will cause training to be initiated on this interface. The progress and success of the open is given by the values of the dot12Status object. Setting this object to 'open' when dot12Status has a value other than 'closed' has no effect. Setting the value of this object to 'close' will move this interface into the 'closed' state and cause all transmit and receive actions to stop. This object will then have to be set to 'open' in order to reinitiate training. Setting the value of this object to 'reset' will reset the interface. On a reset, all MIB counters should retain their values. This will cause the MAC to initiate an acInitializeMAC action as specified in IEEE 802.12. This will cause training to be reinitiated on this interface. Setting the value of this object to 'noOp' has no effect. When read, this object will always have a value of 'noOp'. The 'open' and 'close' values correspond to the 'up' and 'down' values of MIB-II's ifAdminStatus and ifOperStatus, i.e., the setting of ifAdminStatus and dot12Commands affects the values of both ifOperStatus and dot12Status." REFERENCE John Flick Expires March 8, 1995 [Page 14] Internet Draft IEEE 802.12 Interface MIB September 8 1995 "IEEE 802.12, Layer Management, 13.2.5.2.2, acOpen, acClose, acInitializeMAC. Also, RFC1231 IEEE802.5 Token Ring MIB, dot5Commands." ::= { dot12ConfigEntry 7 } dot12Status OBJECT-TYPE SYNTAX INTEGER { opened(1), closed(2), opening(3), openFailure(5), linkFailure(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current interface status with respect to training. One of the following values: opened - Training has completed successfully. closed - MAC has been disabled by setting dot12Commands to 'close'. opening - MAC is in training. Training signals have been received. openFailure - Passed 24 error-free packets, but there is a problem, noted in the training configuration bits (dot12LastTrainingConfig). linkFailure - Training signals not received, or could not pass 24 error-free packets. Whenever the dot12Commands object is set to 'close', the MAC will go silent, dot12Status will be 'closed', and ifOperStatus will be 'down'. When the dot12Commands object is set to 'open', the end node will send Training_Up to the master and initially go to the 'linkFailure' state. When the master sends back Training_Down, dot12Status will change to the 'opening' state and training packets will be transferred. After all of the training packets have been passed, dot12Status will change to 'linkFailure' John Flick Expires March 8, 1995 [Page 15] Internet Draft IEEE 802.12 Interface MIB September 8 1995 if 24 consecutive error-free packets were not passed, 'opened' if 24 consecutive error-free packets were passed and the training configuration bits were OK, or 'openFailure' if there were 24 consecutive error-free packets, but there was a problem with the training configuration bits. When in the 'openFailure' state, the dot12LastTrainingConfig object will contain the configuration bits from the last training packet which can be examined to determine the exact reason for the training configuration failure. If training did not succeed (dot12Status is 'linkFailure' or 'openFailure), the entire process will be restarted after MAC_Retraining_Delay_Timer seconds. If training does succeed (dot12Status is 'opened'), ifOperStatus will be 'up'." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aMACStatus." ::= { dot12ConfigEntry 8 } dot12CurrentFramingType OBJECT-TYPE SYNTAX INTEGER { frameType88023(1), frameType88025(2), frameTypeUnknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "When dot12DesiredFramingType is one of 'frameType88023' or 'frameType88025', this is the type of framing asserted by the interface. When dot12DesiredFramingType is 'frameTypeEither', dot12CurrentFramingType shall be one of 'frameType88023' or 'frameType88025' when the dot12Status is 'opened'. When the dot12Status is anything other than 'opened', dot12CurrentFramingType shall take the value of 'frameTypeUnknown'." ::= { dot12ConfigEntry 9 } John Flick Expires March 8, 1995 [Page 16] Internet Draft IEEE 802.12 Interface MIB September 8 1995 dot12ControlMode OBJECT-TYPE SYNTAX INTEGER { masterMode(1), slaveMode(2), learn(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to configure and report whether or not this interface is operating in master mode. In a Demand Priority network, end node interfaces typically operate in slave mode, while switch interfaces may control the Demand Priority protocol and operate in master mode. This object may be implemented as a read-only object by those agents and interfaces that do not implement software control of master mode. In particular, interfaces that cannot operate in master mode, and interfaces on which master mode is controlled by a pushbutton on the device, should implement this object read-only. Some interfaces do not require network management configuration of this feature and can autosense whether to use master mode or slave mode. The value 'learn' is used for that purpose. While autosense is taking place, the value 'learn' is returned. A network management operation which modifies the value of dot12ControlMode causes the interface to retrain." ::= { dot12ConfigEntry 10 } dot12StatTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot12StatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for a collection of 802.12 interfaces attached to a particular system." ::= { dot12MIBObjects 2 } dot12StatEntry OBJECT-TYPE SYNTAX Dot12StatEntry MAX-ACCESS not-accessible John Flick Expires March 8, 1995 [Page 17] Internet Draft IEEE 802.12 Interface MIB September 8 1995 STATUS current DESCRIPTION "Statistics for a particular interface to an 802.12 medium. The receive statistics in this table apply only to packets received by this station (i.e., packets whose destination address is either the local station address, the broadcast address, or a multicast address that this station is receiving, unless the station is in promiscuous mode)." INDEX { ifIndex } ::= { dot12StatTable 1 } Dot12StatEntry ::= SEQUENCE { dot12InHighPriorityFrames Counter32, dot12InHighPriorityOctets Counter32, dot12InNormPriorityFrames Counter32, dot12InNormPriorityOctets Counter32, dot12InIPMErrors Counter32, dot12InOversizeFrameErrors Counter32, dot12InDataErrors Counter32, dot12InNullAddressedFrames Counter32, dot12OutHighPriorityFrames Counter32, dot12OutHighPriorityOctets Counter32, dot12TransitionIntoTrainings Counter32, dot12HCInHighPriorityOctets Counter64, dot12HCInNormPriorityOctets Counter64, dot12HCOutHighPriorityOctets Counter64 } dot12InHighPriorityFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of high priority frames that have been received on this interface. Includes both good and bad high priority frames, as well as high priority training frames. Does not include normal priority frames which were priority promoted." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aHighPriorityFramesReceived." ::= { dot12StatEntry 1 } dot12InHighPriorityOctets OBJECT-TYPE John Flick Expires March 8, 1995 [Page 18] Internet Draft IEEE 802.12 Interface MIB September 8 1995 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in high priority frames that have been received on this interface. This counter is incremented by OctetCount for each frame received on this interface which is counted by dot12InHighPriorityFrames. Note that this counter will roll over very quickly. It is provided for backward compatibility for Network Management protocols that do not support 64 bit counters (e.g. SNMP version 1)." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aHighPriorityOctetsReceived." ::= { dot12StatEntry 2 } dot12InNormPriorityFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of normal priority frames that have been received on this interface. Includes both good and bad normal priority frames, as well as normal priority training frames and normal priority frames which were priority promoted." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aNormalPriorityFramesReceived." ::= { dot12StatEntry 3 } dot12InNormPriorityOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in normal priority frames that have been received on this interface. This counter is incremented by OctetCount for each frame received on this interface which is counted by dot12InNormPriorityFrames. John Flick Expires March 8, 1995 [Page 19] Internet Draft IEEE 802.12 Interface MIB September 8 1995 Note that this counter will roll over very quickly. It is provided for backward compatibility for Network Management protocols that do not support 64 bit counters (e.g. SNMP version 1)." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aNormalPriorityOctetsReceived." ::= { dot12StatEntry 4 } dot12InIPMErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of frames that have been received on this interface with an invalid packet marker and no PMI errors. A repeater will write an invalid packet marker to the end of a frame containing errors as it is forwarded through the repeater to the other ports. This counter is incremented by one for each frame received on this interface which has had an invalid packet marker added to the end of the frame." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aIPMFramesReceived." ::= { dot12StatEntry 5 } dot12InOversizeFrameErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of oversize frames received on this interface. This counter is incremented by one for each frame received on this interface whose OctetCount is larger than the maximum legal frame size. The frame size which causes this counter to increment is dependent on the current framing type." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aOversizeFramesReceived." ::= { dot12StatEntry 6 } dot12InDataErrors OBJECT-TYPE John Flick Expires March 8, 1995 [Page 20] Internet Draft IEEE 802.12 Interface MIB September 8 1995 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of errored frames received on this interface. This counter is incremented by one for each frame received on this interface with any of the following errors: bad FCS (with no IPM), PMI errors (excluding frames with an IPM as the only PMI error), undersize, bad start of frame delimiter, or bad end of packet marker. Does not include frames counted by dot12InIPMErrors, dot12InNullAddressedFrames, or dot12InOversizeFrameErrors. This counter indicates problems with the cable directly attached to this interface, while dot12InIPMErrors indicates problems with remote cables." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aDataErrorFramesReceived." ::= { dot12StatEntry 7 } dot12InNullAddressedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of null addressed frames received on this interface. This counter is incremented by one for each frame received on this interface with a destination MAC address consisting of all zero bits. Both void and training frames are included in this counter. Note that since this station would normally not receive null addressed frames, this counter is only incremented when this station is operating in promiscuous mode." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aNullAddressedFramesReceived." ::= { dot12StatEntry 8 } dot12OutHighPriorityFrames OBJECT-TYPE SYNTAX Counter32 John Flick Expires March 8, 1995 [Page 21] Internet Draft IEEE 802.12 Interface MIB September 8 1995 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one for each high priority frame successfully transmitted out this interface." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aHighPriorityFramesTransmitted." ::= { dot12StatEntry 9 } dot12OutHighPriorityOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by OctetCount for each frame counted by dot12OutHighPriorityFrames. Note that this counter will roll over very quickly. It is provided for backward compatibility for Network Management protocols that do not support 64 bit counters (e.g. SNMP version 1)." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aHighPriorityOctetsTransmitted." ::= { dot12StatEntry 10 } dot12TransitionIntoTrainings OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of times this interface has entered the training state. This counter is incremented by one each time dot12Status transitions to 'linkFailure' from any state other than 'opening' or 'openFailure'." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aTransitionsIntoTraining." ::= { dot12StatEntry 11 } dot12HCInHighPriorityOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current John Flick Expires March 8, 1995 [Page 22] Internet Draft IEEE 802.12 Interface MIB September 8 1995 DESCRIPTION "This object is a count of the number of octets contained in high priority frames that have been received on this interface. This counter is incremented by OctetCount for each frame received on this interface which is counted by dot12InHighPriorityFrames. This counter is a 64 bit version of dot12InHighPriorityOctets. It should be used by Network Management protocols which support 64 bit counters (e.g. SNMPv2)." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aHighPriorityOctetsReceived." ::= { dot12StatEntry 12 } dot12HCInNormPriorityOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in normal priority frames that have been received on this interface. This counter is incremented by OctetCount for each frame received on this interface which is counted by dot12InNormPriorityFrames. This counter is a 64 bit version of dot12InNormPriorityOctets. It should be used by Network Management protocols which support 64 bit counters (e.g. SNMPv2)." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aNormalPriorityOctetsReceived." ::= { dot12StatEntry 13 } dot12HCOutHighPriorityOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by OctetCount for each frame counted by dot12OutHighPriorityFrames. This counter is a 64 bit version of dot12OutHighPriorityOctets. It should be used by John Flick Expires March 8, 1995 [Page 23] Internet Draft IEEE 802.12 Interface MIB September 8 1995 Network Management protocols which support 64 bit counters (e.g. SNMPv2)." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aHighPriorityOctetsTransmitted." ::= { dot12StatEntry 14 } dot12PMDTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot12PMDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of information about physical media dependent connectors attached to interfaces." ::= { dot12MIBObjects 3 } dot12PMDEntry OBJECT-TYPE SYNTAX Dot12PMDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single physical media connector." INDEX { ifIndex, dot12PMDIndex } ::= { dot12PMDTable 1 } Dot12PMDEntry ::= SEQUENCE { dot12PMDIndex INTEGER, dot12PMDType OBJECT IDENTIFIER, dot12PMDStatus INTEGER } dot12PMDIndex OBJECT-TYPE SYNTAX INTEGER (1..9) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable uniquely identifies the physical media connector attached to this interface that is described by this entry." ::= { dot12PMDEntry 1 } dot12PMDType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION John Flick Expires March 8, 1995 [Page 24] Internet Draft IEEE 802.12 Interface MIB September 8 1995 "The object identifies the type of physical media in use. An initial set of tranceiver types is defined above. The assignment of new types of tranceivers is managed by the IANA. If the tranceiver type is unknown, the object identifier dot12XcvrTypeUnknown OBJECT IDENTIFIER ::= { 0 0 } is returned." REFERENCE "IEEE 802.12, Layer Management, 13.2.5.2.1, aMediaType." ::= { dot12PMDEntry 2 } dot12PMDStatus OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), operational(3), standby(4), notPresent(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "The current state of the tranceiver. This object may be implemented as a read-only object by those agents that do not implement software control of the tranceiver state. Some agents may not support setting the value of this object to some of the enumerated values. The value other(1) is returned if the tranceiver is in a state other than one of the states 2 through 5. The value unknown(2) is returned when the tranceiver's true state is unknown; for example, when it is being initialized. A tranceiver in the operational(3) state is fully functional, operates, and passes signals to the media independent interface of its attached DTE or repeater port. A tranceiver in standby(4) state is not passing network or training frames, and is not passing John Flick Expires March 8, 1995 [Page 25] Internet Draft IEEE 802.12 Interface MIB September 8 1995 signals to the media independent interface of its attached DTE or repeater port. The value notPresent(5) is used to indicate that the media independent interface has detected that there is no tranceiver present." ::= { dot12PMDEntry 3 } -- conformance information dot12Conformance OBJECT IDENTIFIER ::= { dot12MIB 2 } dot12Compliances OBJECT IDENTIFIER ::= { dot12Conformance 1 } dot12Groups OBJECT IDENTIFIER ::= { dot12Conformance 2 } -- compliance statements dot12Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for managed network entities that have 802.12 interfaces." MODULE -- this module MANDATORY-GROUPS { dot12ConfigGroup, dot12StatsGroup, dot12PMDGroup } OBJECT dot12ControlMode MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required." OBJECT dot12PMDStatus SYNTAX INTEGER { operational(3) } WRITE-SYNTAX INTEGER { operational(3), standby(4) } MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required. The only value that an agent must support is operational(3). Only the operational(3) and standby(4) values make sense in a set operation." ::= { dot12Compliances 1 } John Flick Expires March 8, 1995 [Page 26] Internet Draft IEEE 802.12 Interface MIB September 8 1995 -- units of conformance dot12ConfigGroup OBJECT-GROUP OBJECTS { dot12DesiredFramingType, dot12FramingCapability, dot12DesiredPromiscStatus, dot12TrainingVersion, dot12LastTrainingConfig, dot12Commands, dot12Status, dot12CurrentFramingType, dot12ControlMode } STATUS current DESCRIPTION "A collection of objects for managing the status and configuration of IEEE 802.12 interfaces." ::= { dot12Groups 1 } dot12StatsGroup OBJECT-GROUP OBJECTS { dot12InHighPriorityFrames, dot12InHighPriorityOctets, dot12InNormPriorityFrames, dot12InNormPriorityOctets, dot12InIPMErrors, dot12InOversizeFrameErrors, dot12InDataErrors, dot12InNullAddressedFrames, dot12OutHighPriorityFrames, dot12OutHighPriorityOctets, dot12TransitionIntoTrainings, dot12HCInHighPriorityOctets, dot12HCInNormPriorityOctets, dot12HCOutHighPriorityOctets } STATUS current DESCRIPTION "A collection of objects providing statistics for IEEE 802.12 interfaces." ::= { dot12Groups 2 } dot12PMDGroup OBJECT-GROUP OBJECTS { dot12PMDType, dot12PMDStatus } STATUS current DESCRIPTION "A collection of objects for managing the physical media dependent layer of an IEEE 802.12 interface." ::= { dot12Groups 3 } END John Flick Expires March 8, 1995 [Page 27] Internet Draft IEEE 802.12 Interface MIB September 8 1995 5. Acknowledgements This document was produced by the IETF 100VG-AnyLAN Working Group. It is based on the work of IEEE 802.12. 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [4] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets - MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [6] IEEE, "Demand Priority Access Method, Physical Layer and Repeater Specifications for 100 Mb/s Operation", IEEE Standard 802.12" [7] McCloghrie, K., and Kastenholz, F., "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [9] McCloghrie, K., Baker, F., and Decker, E., "IEEE 802.5 Station John Flick Expires March 8, 1995 [Page 28] Internet Draft IEEE 802.12 Interface MIB September 8 1995 Source Routing MIB using SMIv2", RFC 1749, cisco Systems, Inc., December, 1994. 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address John Flick Hewlett Packard Company 8000 Foothills Blvd. M/S 5556 Roseville, CA 95747-5556 Phone: +1 916 785 4018 Email: johnf@hprnd.rose.hp.com John Flick Expires March 8, 1995 [Page 29] Internet Draft IEEE 802.12 Interface MIB September 8 1995 Table of Contents 1. Abstract ................................................... 2 2. The SNMPv2 Network Management Framework .................... 2 2.1. Object Definitions ....................................... 2 3. Overview ................................................... 2 3.1. MAC Addresses ............................................ 3 3.2. Relation to RFC 1213 ..................................... 3 3.3. Relation to RFC 1573 ..................................... 4 3.3.1. Layering Model ......................................... 4 3.3.2. Virtual Circuits ....................................... 4 3.3.3. ifTestTable ............................................ 4 3.3.4. ifRcvAddressTable ...................................... 4 3.3.5. ifPhysAddress .......................................... 4 3.3.6. ifType ................................................. 5 3.3.7. ifMtu .................................................. 5 3.3.8. ifInErrors ............................................. 5 3.3.9. ifOutErrors ............................................ 5 3.3.10. ifPromiscuousMode ..................................... 6 3.4. Relation to RFC 1749 ..................................... 6 3.5. Master Mode Operation .................................... 6 3.6. Normal and High Priority Counters ........................ 6 3.7. Mapping of IEEE 802.12 Managed Objects ................... 7 4. Definitions ................................................ 9 5. Acknowledgements ........................................... 28 6. References ................................................. 28 7. Security Considerations .................................... 29 8. Author's Address ........................................... 29 John Flick Expires March 8, 1995 [Page 30]