RFC relevance of reference

As per Relevance of the word reference, we have this rfc below:

Network Working Group J.
Request for Comments: 2020 Hewlett
Category: Standards Track October 1996

Definitions of Managed Objects for IEEE 802.12

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Table of

1. Introduction ............................................... 1
2. Object Definitions ......................................... 2
3. Overview ................................................... 2
3.1. MAC Addresses ............................................ 3
3.2. Relation to RFC 1213 ..................................... 3
3.3. Relation to RFC 1573 ..................................... 3
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. Specific Interface MIB Objects ......................... 5
3.4. Relation to RFC 1643, RFC 1650, and RFC 1748 ............. 8
3.5. Relation to RFC 1749 ..................................... 8
3.6. Master Mode Operation .................................... 9
3.7. Normal and High Priority Counters ........................ 9
3.8. IEEE 802.12 Training Frames .............................. 10
3.9. Mapping of IEEE 802.12 Managed Objects ................... 12
4. Definitions ................................................ 14
5. Acknowledgements ........................................... 30
6. References ................................................. 30
7. Security Considerations .................................... 31
8. Author's Address ........................................... 31

1.

This memo defines a 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
based on IEEE 802.12.

Flick Standards Track [Page 1]

RFC 2020 IEEE 802.12 Interface MIB October 1996

2. Object

Management information is viewed as a collection of managed objects
residing in a virtual information store, termed the
Information Base (MIB). Collections of related objects are
in MIB modules. MIB modules are written using a subset of
Syntax Notation One (ASN.1) [1] termed the Structure of
Information (SMI) [2]. In particular, each object type is named
an OBJECT IDENTIFIER, an administratively assigned name. The
type together with an object instance serves to uniquely identify
specific instantiation of the object. For human convenience,
often use a textual string, termed the descriptor, to refer to
object type

3.

Instances of these object types represent attributes of an
to an IEEE 802.12 communications medium. At present, IEEE 802.12
media are identified by one value of the ifType object in
Internet-standard MIB

ieee80212(55)

For this interface, the value of the ifSpecific variable in the MIB
II [5] has the OBJECT IDENTIFIER value

dot12MIB OBJECT IDENTIFIER ::= { transmission 45 }

The values for the ifType object are defined by the
textual convention. The Internet Assigned Numbers Authority (IANA
is responsible for the assignment of all Internet numbers,
new ifType values. Therefore, IANA is responsible for
the definition of this textual convention. The current definition
the IANAifType textual convention is available from IANA's World
Web server at

http://www.iana.org/iana

The definitions presented here are based on the IEEE
802.12-1995, [6] Clause 13 "Layer management functions and services",
and Annex C "GDMO Specifications for Demand Priority
Objects". Implementors of these MIB objects should note that
IEEE document explicitly describes (in the form of Pascal pseudocode
when, where, and how various MAC attributes are measured. The
document also describes the effects of MAC actions that may
invoked by manipulating instances of the MIB objects defined here

Flick Standards Track [Page 2]

RFC 2020 IEEE 802.12 Interface MIB October 1996

To the extent that some of the attributes defined in [6]
represented by previously defined objects in the Internet-
MIB [5] or in the Evolution of the Interfaces Group of MIB-II [7],
such attributes are not redundantly represented by objects defined
this memo. Among the attributes represented by objects defined
other memos are the number of octets transmitted or received on
particular interface, the MAC address of an interface, and
information associated with an interface

3.1. MAC

All representations of MAC addresses in this MIB module, and in
related MIB modules (like RFC 1573), are in "canonical" order
by 802.1a, i.e., as if it were transmitted least significant
first. This is true even if the interface is operating in token
framing mode, which requires MAC addresses to be transmitted
significant bit first

3.2. Relation to RFC 1213

This section applies only when this MIB is used in conjunction
the "old" (i.e., pre-RFC 1573) interface group

The relationship between an IEEE 802.12 interface and an interface
the context of the Internet-standard MIB is one-to-one. As such,
value of an ifIndex object instance can be directly used to
corresponding instances of the objects defined herein

3.3. Relation to RFC 1573

RFC 1573, the Interface MIB Evolution, requires that any MIB which
an adjunct of the Interface MIB, clarify specific areas within
Interface MIB. These areas are intentionally left vague in RFC 1573
to avoid over constraining the MIB, thereby precluding management
certain media-types

An agent which implements this MIB module must support
ifGeneralGroup, ifStackGroup, ifHCPacketGroup, and
of RFC 1573.

Section 3.3 of RFC 1573 enumerates several areas which a media
specific MIB must clarify. In addition, there are some objects
RFC 1573 for which additional clarification of how to apply them
an IEEE 802.12 interface would be helpful. Each of these areas
addressed in a following subsection. The implementor is referred
RFC 1573 in order to understand the general intent of these areas

Flick Standards Track [Page 3]

RFC 2020 IEEE 802.12 Interface MIB October 1996

3.3.1. Layering

For the typical usage of this MIB module, there will be no sub-
"above" or "below" the 802.12 Interface. However, this MIB
does not preclude such layering

3.3.2. Virtual

This medium does not support virtual circuits and this area is
applicable to this MIB

3.3.3.

This MIB does not define any tests for media instrumented by
MIB. Implementation of the ifTestTable is not required.
implementation may optionally implement the ifTestTable to
vendor specific tests

3.3.4.

This table contains all IEEE addresses, unicast, multicast,
broadcast, for which this interface will receive packets and
them up to a higher layer entity for consumption. In addition,
the interface is using 802.5 framing mode, the ifRcvAddressTable
contain the functional address mask

In the event that the interface is part of a MAC bridge, this
does not include unicast addresses which are accepted for
forwarding out some other port. This table is explicitly
intended to provide a bridge address filtering mechanism

3.3.5.

This object contains the IEEE 802.12 address which is placed in
source-address field of any frames that originate at this interface
Usually this will be kept in ROM on the interface hardware.
systems may set this address via software

In a system where there are several such addresses the designer has
tougher choice. The address chosen should be the one most likely
be of use to network management (e.g. the address placed in
responses for systems which are primarily IP systems).

If the designer truly can not choose, use of the factory-provided
address is suggested

If the address can not be determined, an octet string of zero
should be returned

Flick Standards Track [Page 4]

RFC 2020 IEEE 802.12 Interface MIB October 1996

The address is stored in binary in this object. The address
stored in "canonical" bit order, that is, the Group Bit is
as the low-order bit of the first octet. Thus, the first byte of
multicast address would have the bit 0x01 set. This is true
when the interface is using token ring framing mode, which
addresses high-order bit first

3.3.6. Specific Interface MIB

The following table provides specific implementation guidelines
the interface group objects in the conformance groups listed above

Object Use for an 802.12

ifIndex Each 802.12 interface is represented by
ifEntry. Interface tables in this
module are indexed by ifIndex

ifDescr Refer to [7].

ifType The IANA reserved value for 802.12 - 55.

ifMtu The value of ifMtu on an 802.12
will depend on the type of framing that
in use on that interface. Changing
dot12DesiredFramingType may have the
of changing ifMtu after the next time
the interface trains.
dot12CurrentFramingType is equal
frameType88023, ifMtu will be equal
1500. When dot12CurrentFramingType
equal to frameType88025, ifMtu will
4464.

ifSpeed The speed of the interface in bits
second. For current 802.12
implementations, this will be equal
100,000,000 (100 million).

ifPhysAddress See Section 3.3.5.

Flick Standards Track [Page 5]

RFC 2020 IEEE 802.12 Interface MIB October 1996

ifAdminStatus Write access is not required. Support
'testing' is not required. Setting
object to 'up' will cause dot12Commands
be set to 'open'. Setting this object
'down' will cause dot12Commands to be
to 'close'. Setting dot12Commands
'open' will set this object to 'up'.
Setting dot12Commands to 'close' will
this object to 'down'.
dot12Commands to 'reset' will have
effect on this object

ifOperStatus When dot12Status is equal to 'opened',
object will be equal to 'up'.
dot12Status is equal to 'closed', 'opening',
'openFailure' or 'linkFailure', this
will be equal to 'down'. Support
'testing' is not required, but may be
to indicate that a vendor specific test
in progress. The value 'dormant' has
meaning for an IEEE 802.12 interface

ifLastChange Refer to [7].

ifInOctets The number of octets in valid MAC
received on this interface, including
MAC header and FCS

ifInUcastPkts Refer to [7].

ifInDiscards Refer to [7].

ifInErrors The sum for this interface
dot12InIPMErrors
dot12InOversizeFrameErrors
dot12InDataErrors, and any
internal errors that may occur in
implementation

ifInUnknownProtos Refer to [7].

ifOutOctets The number of octets transmitted in
frames on this interface, including the
header and FCS

ifOutUcastPkts Refer to [7].

ifOutDiscards Refer to [7].

Flick Standards Track [Page 6]

RFC 2020 IEEE 802.12 Interface MIB October 1996

ifOutErrors The number of implementation-
internal transmit errors on this interface

ifName Locally-significant textual name for
interface (e.g. vg0).

ifInMulticastPkts Refer to [7]. When dot12
is frameType88025, this count
packets addressed to functional addresses

ifInBroadcastPkts Refer to [7].

ifOutMulticastPkts Refer to [7]. When dot12
is frameType88025, this count
packets addressed to functional addresses

ifOutBroadcastPkts Refer to [7].

ifHCInOctets 64-bit version of ifInOctets

ifHCOutOctets 64-bit version of

ifHC*Pkts Not required for 100 MBit interfaces
Future IEEE 802.12 interfaces which
at higher speeds may require
of these counters, but such interfaces
beyond the scope of this memo

ifLinkUpDownTrapEnable Refer to [7]. Default is 'enabled'.

ifHighSpeed The speed of the interface in millions
bits per second. For current 802.12
implementations, this will be equal to 100.

ifPromiscuousMode Reflects whether the interface
successfully trained and is
operating in promiscuous mode
dot12DesiredPromiscStatus is used to
the promiscuous mode to be requested in
next training attempt.
ifPromiscuousMode will
dot12DesiredPromiscStatus and cause
interface to attempt to retrain using
new promiscuous mode. After the
has retrained, ifPromiscuousMode
reflect the mode that is in use, not
mode that was requested

Flick Standards Track [Page 7]

RFC 2020 IEEE 802.12 Interface MIB October 1996

ifConnectorPresent This will normally be 'true'.

ifStackHigherLayer Refer to section 3.3.1

ifRcvAddressAddress Refer to section 3.3.4.

3.4. Relation to RFC 1643, RFC 1650, and RFC 1748

An IEEE 802.12 interface can be configured to operate in
ethernet or token ring framing mode. An IEEE 802.12 interface
the frame format for the configured framing mode, but does not
the media access protocol for ethernet or token ring. Instead,
802.12 defines its own media access protocol, the Demand
Access Method (DPAM).

There are existing standards-track MIB modules for
ethernet-like interfaces and token ring interfaces. At the time
this writing, they are: STD 50, RFC 1643, "Definitions of
Objects for Ethernet-like Interface Types" [8]; RFC 1650,
"Definitions of Managed Objects for Ethernet-like Interface
using SMIv2" [9]; and RFC 1748, "IEEE 802.5 MIB using SMIv2" [10].
These MIB modules are designed to instrument the media
protocol for these respective technologies. Since IEEE 802.12
interfaces do not implement either of these media access protocols
an agent should not implement RFC 1643, RFC 1650, or RFC 1748
IEEE 802.12 interfaces

3.5. Relation to RFC 1749

When an IEEE 802.12 interface is operating in token ring
mode, and the end node supports token ring source routing, the
should implement RFC 1749, the IEEE 802.5 Station Source Routing
[11] for those interfaces

Flick Standards Track [Page 8]

RFC 2020 IEEE 802.12 Interface MIB October 1996

3.6. Master Mode

In an IEEE 802.12 network, "master" devices act as
controllers to decide when to grant requesting end-nodes
to transmit. These master devices may be repeaters, or other
controller devices such as switches

Devices which do not act as network controllers, such as end-nodes
passive switches, are considered to be operating in "slave" mode

The dot12ControlMode object indicates if the interface is
in master mode or slave mode

3.7. Normal and High Priority

The IEEE 802.12 interface MIB does not provide normal
transmit counters. Standardization of normal priority
counters could not be justified -- ifOutUcastPkts
ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets
dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets
suffice. More precisely, the number of normal priority
transmitted can be calculated as

outNormPriorityFrames = ifOutUcastPkts +
ifOutMulticastPkts +
ifOutBroadcastPkts -
dot12

The number of normal priority octets transmitted can be
as

outNormPriorityOctets = ifOutOctets -
dot12

On the other hand, normal priority receive counters are provided
The main reason for this is that the normal priority and
priority counters include errored frames, whereas the ifIn*Pkts
ifInOctets do not include errored frames. dot12
could be calculated, but the calculation is tedious

inNormPriorityFrames = ifInUcastPkts +
ifInMulticastPkts +
ifInBroadcastPkts +
dot12InNullAddressedFrames +
ifInErrors +
ifInDiscards +
ifInUnknownProtos -
dot12

Flick Standards Track [Page 9]

RFC 2020 IEEE 802.12 Interface MIB October 1996

dot12InNormPriorityOctets includes octets in unreadable frames,
is not available elsewhere. The number of octets in
frames can be calculated as

octetsInUnreadableFrames = dot12InNormPriorityOctets +
dot12InHighPriorityOctets -

Also, the total traffic at this interface can be calculated as

traffic = dot12InNormPriorityOctets +
dot12InHighPriorityOctets +

In other words, the normal priority receive counters were
useful, whereas the normal priority transmit counters can be
calculated from other available counters

3.8. IEEE 802.12 Training

Training frames are special MAC frames that are used only during
initialization. Training frames are initially constructed by
device at the lower end of a link, which is the slave mode device
the link. The training frame format is as follows

+----+----+------------+--------------+----------+-----+
| DA | SA | Req Config | Allow Config | Data | FCS |
+----+----+------------+--------------+----------+-----+

DA = destination address (six octets
SA = source address (six octets
Req Config = requested configuration (2 octets
Allow Config = allowed configuration (2 octets
Data = data (594 to 675 octets
FCS = frame check sequence (4 octets

Training frames are always sent with a null destination address.
pass training, an end node must use its source address in the
address field of the training frame. A repeater may use a non-
source address if it has one, or it may use a null source address

Flick Standards Track [Page 10]

RFC 2020 IEEE 802.12 Interface MIB October 1996

The requested configuration field allows the slave mode device
inform the master mode device about itself and to
configuration options. The training response frame from the
mode device contains the slave mode device's requested
from the training request frame. The currently defined format of
requested configuration field as defined in the IEEE
802.12-1995 standard is shown below. Please refer to the
current version of the IEEE document for a more up to
description of this field. In particular, the reserved bits may
used in later versions of the standard

First Octet: Second Octet

7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|v|v|v|r|r|r|r|r| |r|r|r|F|F|P|P|R
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

vvv: The version of the 802.12 training protocol with
the training initiator is compliant. The current
is 100.
r: Reserved bits (set to zero
FF: 00 = frameType88023
01 = frameType88025
10 =
11 =
PP: 00 =
01 =
10 =
11 =
R: 0 = the training initiator is an end
1 = the training initiator is a

The allowed configuration field allows the master mode device
respond with the allowed configuration. The slave mode device
the contents of this field to all zero bits. The master mode
sets the allowed configuration field as follows

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|r|r| |r|r|r|F|F|P|P|R
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

vvv: The version of the 802.12 training protocol with
the training responder is compliant. The current
is 100.

Flick Standards Track [Page 11]

RFC 2020 IEEE 802.12 Interface MIB October 1996

D: 0 = No duplicate address has been detected
1 = Duplicate address has been
C: 0 = The requested configuration is compatible with
network
1 = The requested configuration is not compatible
the network. In this case, the FF, PP, and R
indicate the configuration that would be allowed
N: 0 = Access will be allowed, providing the
is compatible (C = 0).
1 = Access is not granted because of

r: Reserved bits (set to zero
FF: 00 = frameType88023 will be
01 = frameType88025 will be
10 =
11 =
PP: 00 =
01 =
10 =
11 =
R: 0 = Requested access as an end node is
1 = Requested access as a repeater is

Again, note that the most recent version of the IEEE 802.12
should be consulted for the most up to date definition of
requested configuration and allowed configuration fields

The data field contains between 594 and 675 octets and is filled
by the training initiator. The first 55 octets may be used
vendor specific protocol information. The remaining octets are
zeros. The length of the training frame combined with
requirement that 24 consecutive training frames be received
error to complete training ensures that marginal links will
complete training

3.9. Mapping of IEEE 802.12 Managed

The following table lists all the managed objects defined
oEndNode in the IEEE 802.12 Standard, and the corresponding
objects

IEEE 802.12 Managed Object Corresponding SNMP

.aBroadcastFramesReceived IF-MIB -
.aBroadcastFramesTransmitted IF-MIB -
.aDataErrorFramesReceived dot12
.aDesiredFramingType dot12

Flick Standards Track [Page 12]

RFC 2020 IEEE 802.12 Interface MIB October 1996

.aDesiredPromiscuousStatus dot12
.aFramesTransmitted IF-MIB - ifOutUCastPkts +
ifOutMulticastPkts +

.aFramingCapability dot12
.aFunctionalAddresses IF-MIB -
.aHighPriorityFramesReceived dot12
.aHighPriorityFramesTransmitted dot12
.aHighPriorityOctetsReceived dot12InHighPriorityOctets
dot12
.aHighPriorityOctetsTransmitted dot12OutHighPriorityOctets
dot12
.aIPMFramesReceived dot12
.aLastTrainingConfig dot12
.aMACID IF-MIB -
.aMACStatus dot12
.aMACVersion dot12
.aMediaType Tranceiver MIB
.aMulticastFramesReceived IF-MIB -
.aMulticastFramesTransmitted IF-MIB -
.aMulticastReceiveStatus IF-MIB -
.aNormalPriorityFramesReceived dot12
.aNormalPriorityOctetsReceived dot12InNormPriorityOctets
dot12
.aNullAddressedFramesReceived dot12
.aOctetsTransmitted IF-MIB - ifOutOctets

.aOversizeFramesReceived dot12
.aReadableFramesReceived IF-MIB - ifInUcastPkts +
ifInMulticastPkts +

.aReadableOctetsReceived IF-MIB - ifInOctets

.aReadMulticastList IF-MIB -
.aReadWriteMACAddress IF-MIB -
.aTransitionsIntoTraining dot12
.acAddGroupAddress IF-MIB -
.acClose dot12Commands: 'close
.acDeleteGroupAddress IF-MIB -
.acExecuteSelftest IF-MIB -
.acInitializeMAC dot12Commands: 'reset
.acOpen dot12Commands: 'open

Flick Standards Track [Page 13]

RFC 2020 IEEE 802.12 Interface MIB October 1996

4.

DOT12-IF-MIB DEFINITIONS ::=

transmission, Counter32, Counter64, OBJECT-TYPE
MODULE-
FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-
FROM SNMPv2-

FROM IF-MIB

dot12MIB MODULE-
LAST-UPDATED "9602220452Z" -- February 22, 1996
ORGANIZATION "IETF 100VG-AnyLAN MIB Working Group
CONTACT-
" John

Postal: Hewlett Packard
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

"This MIB module describes objects
managing IEEE 802.12 interfaces."
::= { transmission 45 }

dot12MIBObjects OBJECT IDENTIFIER ::= { dot12MIB 1 }

dot12ConfigTable OBJECT-
SYNTAX SEQUENCE OF Dot12
MAX-ACCESS not-
STATUS

"Configuration information for a collection
802.12 interfaces attached to a
system."
::= { dot12MIBObjects 1 }

dot12ConfigEntry OBJECT-
SYNTAX Dot12
MAX-ACCESS not-
STATUS

Flick Standards Track [Page 14]

RFC 2020 IEEE 802.12 Interface MIB October 1996

"Configuration for a particular interface to
802.12 medium."
INDEX { ifIndex }
::= { dot12ConfigTable 1 }

Dot12ConfigEntry ::=
SEQUENCE {
dot12CurrentFramingType INTEGER
dot12DesiredFramingType INTEGER
dot12FramingCapability INTEGER
dot12DesiredPromiscStatus INTEGER
dot12TrainingVersion INTEGER
dot12LastTrainingConfig OCTET STRING
dot12Commands INTEGER
dot12Status INTEGER
dot12ControlMode
}

dot12CurrentFramingType OBJECT-
SYNTAX INTEGER {
frameType88023(1),
frameType88025(2),
frameTypeUnknown(3)
}
MAX-ACCESS read-
STATUS

"When dot12DesiredFramingType is one
'frameType88023' or 'frameType88025', this is
type of framing asserted by the interface

When dot12DesiredFramingType is 'frameTypeEither',
dot12CurrentFramingType shall be one
'frameType88023' or 'frameType88025' when
dot12Status is 'opened'. When the dot12Status
anything other than 'opened',
dot12CurrentFramingType shall take the value
'frameTypeUnknown'."
::= { dot12ConfigEntry 1 }

dot12DesiredFramingType OBJECT-
SYNTAX INTEGER {
frameType88023(1),
frameType88025(2),
frameTypeEither(3)
}
MAX-ACCESS read-
STATUS

Flick Standards Track [Page 15]

RFC 2020 IEEE 802.12 Interface MIB October 1996

"The type of framing which will be requested
the interface during the next interface
initialization or open action

In master mode, this is the framing mode
will be granted by the interface. Note
for a master mode interface, this object must
equal to 'frameType88023' or 'frameType88025',
since a master mode interface cannot
'frameTypeEither'."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aDesiredFramingType."
::= { dot12ConfigEntry 2 }

dot12FramingCapability OBJECT-
SYNTAX INTEGER {
frameType88023(1),
frameType88025(2),
frameTypeEither(3)
}
MAX-ACCESS read-
STATUS

"The type of framing this interface is capable
supporting."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aFramingCapability."
::= { dot12ConfigEntry 3 }

dot12DesiredPromiscStatus OBJECT-
SYNTAX INTEGER {
singleAddressMode(1),
promiscuousMode(2)
}
MAX-ACCESS read-
STATUS

"This object is used to select the
mode that this interface will request in the
training packet issued on this interface
Whether the repeater grants the requested
must be verified by examining the state of the
bits in the corresponding instance
dot12LastTrainingConfig

Flick Standards Track [Page 16]

RFC 2020 IEEE 802.12 Interface MIB October 1996

In master mode, this object controls whether
not promiscuous mode will be granted by
interface when requested by the lower
device

Note that this object indicates the desired
for the next time the interface trains.
currently active mode will be reflected
dot12LastTrainingConfig and in ifPromiscuousMode."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aDesiredPromiscuousStatus."
::= { dot12ConfigEntry 4 }

dot12TrainingVersion OBJECT-
SYNTAX INTEGER (0..7)
MAX-ACCESS read-
STATUS

"The value that will be used in the version
(vvv bits) in training frames on this interface
This is the highest version number supported
this MAC."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aMACVersion."
::= { dot12ConfigEntry 5 }

dot12LastTrainingConfig OBJECT-
SYNTAX OCTET STRING (SIZE(2))
MAX-ACCESS read-
STATUS

"This 16 bit field contains the
bits from the most recent error-free
frame received during training on this interface
Training request frames are received when
master mode, while training response frames
received in slave mode. On master mode interfaces
this object contains the contents of
requested configuration field of the most
training request frame. On slave mode interfaces
this object contains the contents of the
configuration field of the most recent
response frame. The format of the current
of this field is described in section 3.8.
refer to the most recent version of the
802.12 standard for the most up-to-date

Flick Standards Track [Page 17]

RFC 2020 IEEE 802.12 Interface MIB October 1996

of the format of this object."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aLastTrainingConfig."
::= { dot12ConfigEntry 6 }

dot12Commands OBJECT-
SYNTAX INTEGER {
noOp(1),
open(2),
reset(3),
close(4)
}
MAX-ACCESS read-
STATUS

"If the current value of dot12Status is 'closed',
setting the value of this object to 'open'
change the corresponding instance of MIB-II'
ifAdminStatus to 'up', cause this interface
enter the 'opening' state, and will cause
to be initiated on this interface. The
and success of the open is given by the values
the dot12Status object. Setting this object
'open' when dot12Status has a value other
'closed' has no effect

Setting the corresponding instance of
to 'up' when the current value of dot12Status
'closed' will have the same effect as setting
object to 'open'. Setting ifAdminStatus to 'up
when dot12Status has a value other than 'closed
has no effect

Setting the value of this object to 'close'
move this interface into the 'closed' state
cause all transmit and receive actions to stop
This object will then have to be set to 'open'
order to reinitiate training

Setting the corresponding instance of
to 'down' will have the same effect as setting
object to 'close'.

Setting the value of this object to 'reset'
the current value of dot12Status has a value
than 'closed' will reset the interface. On
reset, all MIB counters should retain their values

Flick Standards Track [Page 18]

RFC 2020 IEEE 802.12 Interface MIB October 1996

This will cause the MAC to initiate
acInitializeMAC action as specified in IEEE 802.12.
This will cause training to be reinitiated on
interface. Setting this object to 'reset'
dot12Status has a value of 'closed' has no effect
Setting this object to 'reset' has no effect on
corresponding instance of ifAdminStatus

Setting the value of this object to 'noOp' has
effect

When read, this object will always have a
of 'noOp'."

"IEEE Standard 802.12-1995, 13.2.5.2.2,
acOpen, acClose, acInitializeMAC
Also, RFC1231 IEEE802.5 Token Ring MIB
dot5Commands."
::= { dot12ConfigEntry 7 }

dot12Status OBJECT-
SYNTAX INTEGER {
opened(1),
closed(2),
opening(3),
openFailure(5),
linkFailure(6)
}
MAX-ACCESS read-
STATUS

"The current interface status with respect
training. One of the following values

opened - Training has
successfully
closed - MAC has been disabled
setting dot12Commands
'close'.
opening - MAC is in training.
signals have been received
openFailure - Passed 24 error-free packets
but there is a problem,
in the training
bits (dot12LastTrainingConfig).
linkFailure - Training signals not received
or could not pass 24 error-
packets

Flick Standards Track [Page 19]

RFC 2020 IEEE 802.12 Interface MIB October 1996

Whenever the dot12Commands object is set
'close' or ifAdminStatus is set to 'down', the
will go silent, dot12Status will be 'closed',
ifOperStatus will be 'down'.

When the value of this object is equal to 'closed
and the dot12Commands object is set to 'open'
the ifAdminStatus object is set to 'up',
will be initiated on this interface. When
value of this object is not equal to 'closed'
the dot12Commands object is set to 'reset',
training will be reinitiated on this interface
Note that sets of some other objects (e.g
dot12ControlMode) or external events (e.g.
protocol violations) may also cause training to
reinitiated on this interface

When training is initiated or reinitiated on
interface, the end node will send Training_Up
the master and initially go to the 'linkFailure
state and ifOperStatus will go to 'down'.
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
passed, dot12Status will change to 'linkFailure
if 24 consecutive error-free packets were
passed, 'opened' if 24 consecutive error-
packets were passed and the
configuration bits were OK, or 'openFailure'
there were 24 consecutive error-free packets,
there was a problem with the
configuration bits

When in the 'openFailure' state,
dot12LastTrainingConfig object will contain
configuration bits from the last
packet which can be examined to determine
exact reason for the training
failure

If training did not succeed (dot12Status
'linkFailure' or 'openFailure), the
process will be restarted
MAC_Retraining_Delay_Timer seconds

If training does succeed (dot12Status changes

Flick Standards Track [Page 20]

RFC 2020 IEEE 802.12 Interface MIB October 1996

'opened'), ifOperStatus will change to 'up'.
training does not succeed (dot12Status changes
'linkFailure' or 'openFailure'), ifOperStatus
remain 'down'."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aMACStatus."
::= { dot12ConfigEntry 8 }

dot12ControlMode OBJECT-
SYNTAX INTEGER {
masterMode(1),
slaveMode(2),
learn(3)
}
MAX-ACCESS read-
STATUS

"This object is used to configure and
whether or not this interface is operating
master mode. In a Demand Priority network,
node interfaces typically operate in slave mode
while switch interfaces may control the
Priority protocol and operate in master mode

This object may be implemented as a read-
object by those agents and interfaces that do
implement software control of master mode.
particular, interfaces that cannot operate
master mode, and interfaces on which master
is controlled by a pushbutton on the device
should implement this object read-only

Some interfaces do not require network
configuration of this feature and can
whether to use master mode or slave mode.
value 'learn' is used for that purpose.
autosense is taking place, the value 'learn'
returned

A network management operation which modifies
value of dot12ControlMode causes the
to retrain."
::= { dot12ConfigEntry 9 }

dot12StatTable OBJECT-
SYNTAX SEQUENCE OF Dot12
MAX-ACCESS not-

Flick Standards Track [Page 21]

RFC 2020 IEEE 802.12 Interface MIB October 1996

STATUS

"Statistics for a collection of 802.12
attached to a particular system."
::= { dot12MIBObjects 2 }

dot12StatEntry OBJECT-
SYNTAX Dot12
MAX-ACCESS not-
STATUS

"Statistics for a particular interface to
802.12 medium. The receive statistics in
table apply only to packets received by
station (i.e., packets whose destination
is either the local station address,
broadcast address, or a multicast address
this station is receiving, unless the station
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-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"This object is a count of high priority
that have been received on this interface
Includes both good and bad high priority frames

Flick Standards Track [Page 22]

RFC 2020 IEEE 802.12 Interface MIB October 1996

as well as high priority training frames.
not include normal priority frames which
priority promoted."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityFramesReceived."
::= { dot12StatEntry 1 }

dot12InHighPriorityOctets OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"This object is a count of the number of
contained in high priority frames that have
received on this interface. This counter
incremented by OctetCount for each frame
on this interface which is counted
dot12InHighPriorityFrames

Note that this counter will roll over
quickly. It is provided for
compatibility for Network Management
that do not support 64 bit counters (e.g.
version 1)."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityOctetsReceived."
::= { dot12StatEntry 2 }

dot12InNormPriorityFrames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"This object is a count of normal priority
that have been received on this interface
Includes both good and bad normal
frames, as well as normal priority
frames and normal priority frames which
priority promoted."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aNormalPriorityFramesReceived."
::= { dot12StatEntry 3 }

dot12InNormPriorityOctets OBJECT-
SYNTAX Counter32

Flick Standards Track [Page 23]

RFC 2020 IEEE 802.12 Interface MIB October 1996

MAX-ACCESS read-
STATUS

"This object is a count of the number of
contained in normal priority frames that
been received on this interface. This counter
incremented by OctetCount for each frame
on this interface which is counted
dot12InNormPriorityFrames

Note that this counter will roll over
quickly. It is provided for
compatibility for Network Management
that do not support 64 bit counters (e.g.
version 1)."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aNormalPriorityOctetsReceived."
::= { dot12StatEntry 4 }

dot12InIPMErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"This object is a count of the number of
that have been received on this interface with
invalid packet marker and no PMI errors.
repeater will write an invalid packet marker
the end of a frame containing errors as it
forwarded through the repeater to the
ports. This counter is incremented by one
each frame received on this interface which
had an invalid packet marker added to the end
the frame."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aIPMFramesReceived."
::= { dot12StatEntry 5 }

dot12InOversizeFrameErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"This object is a count of oversize
received on this interface. This counter
incremented by one for each frame received

Flick Standards Track [Page 24]

RFC 2020 IEEE 802.12 Interface MIB October 1996

this interface whose OctetCount is larger
the maximum legal frame size. The frame
which causes this counter to increment
dependent on the current framing type."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aOversizeFramesReceived."
::= { dot12StatEntry 6 }

dot12InDataErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"This object is a count of errored
received on this interface. This counter
incremented by one for each frame received
this interface with any of the following errors
bad FCS (with no IPM), PMI errors (
frames with an IPM as the only PMI error),
undersize, bad start of frame delimiter, or
end of packet marker. Does not include
counted by dot12InIPMErrors
dot12InNullAddressedFrames,
dot12InOversizeFrameErrors

This counter indicates problems with the
directly attached to this interface,
dot12InIPMErrors indicates problems with
cables."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aDataErrorFramesReceived."
::= { dot12StatEntry 7 }

dot12InNullAddressedFrames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"This object is a count of null addressed
received on this interface. This counter
incremented by one for each frame received
this interface with a destination MAC
consisting of all zero bits. Both void
training frames are included in this counter

Note that since this station would normally

Flick Standards Track [Page 25]

RFC 2020 IEEE 802.12 Interface MIB October 1996

receive null addressed frames, this counter
only incremented when this station is
in promiscuous mode or in training."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aNullAddressedFramesReceived."
::= { dot12StatEntry 8 }

dot12OutHighPriorityFrames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"This counter is incremented by one for each
priority frame successfully transmitted out
interface."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityFramesTransmitted."
::= { dot12StatEntry 9 }

dot12OutHighPriorityOctets OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"This counter is incremented by OctetCount
each frame counted by dot12OutHighPriorityFrames

Note that this counter will roll over
quickly. It is provided for
compatibility for Network Management
that do not support 64 bit counters (e.g.
version 1)."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityOctetsTransmitted."
::= { dot12StatEntry 10 }

dot12TransitionIntoTrainings OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS

"This object is a count of the number of
this interface has entered the training state
This counter is incremented by one each
dot12Status transitions to 'linkFailure' from

Flick Standards Track [Page 26]

RFC 2020 IEEE 802.12 Interface MIB October 1996

state other than 'opening' or 'openFailure'."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aTransitionsIntoTraining."
::= { dot12StatEntry 11 }

dot12HCInHighPriorityOctets OBJECT-
SYNTAX Counter64
MAX-ACCESS read-
STATUS

"This object is a count of the number of
contained in high priority frames that have
received on this interface. This counter
incremented by OctetCount for each frame
on this interface which is counted
dot12InHighPriorityFrames

This counter is a 64 bit version
dot12InHighPriorityOctets. It should be used
Network Management protocols which support 64
counters (e.g. SNMPv2)."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityOctetsReceived."
::= { dot12StatEntry 12 }

dot12HCInNormPriorityOctets OBJECT-
SYNTAX Counter64
MAX-ACCESS read-
STATUS

"This object is a count of the number of
contained in normal priority frames that
been received on this interface. This counter
incremented by OctetCount for each frame
on this interface which is counted
dot12InNormPriorityFrames

This counter is a 64 bit version
dot12InNormPriorityOctets. It should be used
Network Management protocols which support 64
counters (e.g. SNMPv2)."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aNormalPriorityOctetsReceived."
::= { dot12StatEntry 13 }

Flick Standards Track [Page 27]

RFC 2020 IEEE 802.12 Interface MIB October 1996

dot12HCOutHighPriorityOctets OBJECT-
SYNTAX Counter64
MAX-ACCESS read-
STATUS

"This counter is incremented by OctetCount
each frame counted by dot12OutHighPriorityFrames

This counter is a 64 bit version
dot12OutHighPriorityOctets. It should be used
Network Management protocols which support 64
counters (e.g. SNMPv2)."

"IEEE Standard 802.12-1995, 13.2.5.2.1,
aHighPriorityOctetsTransmitted."
::= { dot12StatEntry 14 }

-- conformance

dot12Conformance OBJECT IDENTIFIER ::= { dot12MIB 2 }

dot12Compliances OBJECT IDENTIFIER ::= { dot12Conformance 1 }
dot12Groups OBJECT IDENTIFIER ::= { dot12Conformance 2 }

-- compliance

dot12Compliance MODULE-
STATUS

"The compliance statement for managed
entities that have 802.12 interfaces."

MODULE -- this
MANDATORY-GROUPS { dot12ConfigGroup, dot12StatsGroup }

OBJECT dot12
MIN-ACCESS read-

"Write access to this object is not required."

OBJECT dot12
MIN-ACCESS read-

"Write access to this object is not required."

OBJECT dot12
MIN-ACCESS read-

Flick Standards Track [Page 28]

RFC 2020 IEEE 802.12 Interface MIB October 1996

"Write access to this object is not required."

OBJECT dot12
MIN-ACCESS read-

"Write access to this object is not required."
::= { dot12Compliances 1 }

-- units of

dot12ConfigGroup OBJECT-
OBJECTS { dot12DesiredFramingType
dot12FramingCapability
dot12DesiredPromiscStatus
dot12TrainingVersion
dot12LastTrainingConfig
dot12Commands, dot12Status
dot12CurrentFramingType
dot12ControlMode }
STATUS

"A collection of objects for managing the
and configuration of IEEE 802.12 interfaces."
::= { dot12Groups 1 }

dot12StatsGroup OBJECT-
OBJECTS { dot12InHighPriorityFrames
dot12InHighPriorityOctets
dot12InNormPriorityFrames
dot12InNormPriorityOctets
dot12InIPMErrors
dot12InOversizeFrameErrors
dot12InDataErrors
dot12InNullAddressedFrames
dot12OutHighPriorityFrames
dot12OutHighPriorityOctets
dot12TransitionIntoTrainings
dot12HCInHighPriorityOctets
dot12HCInNormPriorityOctets
dot12HCOutHighPriorityOctets }
STATUS

"A collection of objects providing statistics
IEEE 802.12 interfaces."
::= { dot12Groups 2 }

Flick Standards Track [Page 29]

RFC 2020 IEEE 802.12 Interface MIB October 1996

5.

This document was produced by the IETF 100VG-AnyLAN Working Group
It is based on the work of IEEE 802.12.

6.

[1] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization.
Standard 8824 (December, 1987).

[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Structure of Management Information for
2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
SNMP Research, Inc., Cisco Systems, Inc., Dover
Consulting, Inc., International Network Services, January 1996.

[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Textual Conventions for Version 2 of the
Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.

[4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Conformance Statements for Version 2 of
Simple Network Management Protocol (SNMPv2)", RFC 1904,
Research, Inc., Cisco Systems, Inc., Dover Beach Consulting
Inc., International Network Services, January 1996.

[5] McCloghrie, K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets - MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International
March 1991.

[6] IEEE, "Demand Priority Access Method, Physical Layer
Repeater Specifications for 100 Mb/s Operation", IEEE
802.12-1995"

[7] McCloghrie, K., and Kastenholz, F., "Evolution of the
Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software
January 1994.

[8] Kastenholz, F., "Definitions of Managed Objects for
Ethernet-like Interface Types", STD 50, RFC 1643, FTP Software
Inc., July, 1994.

Flick Standards Track [Page 30]

RFC 2020 IEEE 802.12 Interface MIB October 1996

[9] Kastenholz, F., "Definitions of Managed Objects for
Ethernet-like Interface Types using SMIv2", RFC 1650,
Software, Inc., August, 1994.

[10] McCloghrie, K., and Decker, E., "IEEE 802.5 MIB using SMIv2",
RFC 1748, Cisco Systems, Inc., December, 1994.

[11] McCloghrie, K., Baker, F., and Decker, E., "IEEE 802.5
Source Routing MIB using SMIv2", RFC 1749, Cisco Systems, Inc.,
December, 1994.

7. Security

Security issues are not discussed in this memo

8. Author's

John
Hewlett Packard
8000 Foothills Blvd. M/S 5556
Roseville, CA 95747-5556

Phone: +1 916 785 4018
Email: johnf@hprnd.rose.hp.

Flick Standards Track [Page 31]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX