< draft-ietf-vgmib-interfaces-mib-05.txt   draft-ietf-vgmib-interfaces-mib-06.txt >
Internet Draft IEEE 802.12 Interface MIB December 15 1995 Internet Draft IEEE 802.12 Interface MIB February 22 1996
Definitions of Managed Objects for IEEE 802.12 Interfaces Definitions of Managed Objects for IEEE 802.12 Interfaces
December 15, 1995 February 22, 1996
John Flick John Flick
Hewlett Packard Company Hewlett Packard Company
8000 Foothills Blvd. M/S 5556 8000 Foothills Blvd. M/S 5556
Roseville, CA 95747-5556 Roseville, CA 95747-5556
johnf@hprnd.rose.hp.com johnf@hprnd.rose.hp.com
<draft-ietf-vgmib-interfaces-mib-05.txt> <draft-ietf-vgmib-interfaces-mib-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
1. Abstract 1. Introduction
This memo defines an experimental portion of the Management This memo defines a portion of the Management Information Base (MIB)
Information Base (MIB) for use with network management protocols in for use with network management protocols in TCP/IP-based internets.
TCP/IP-based internets. In particular, it defines objects for In particular, it defines objects for managing network interfaces
managing network interfaces based on IEEE 802.12. based on IEEE 802.12.
2. Object Definitions 2. Object Definitions
Management information is viewed as a collection of managed objects, Management information is viewed as a collection of managed objects,
residing in a virtual information store, termed the Management residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined Information Base (MIB). Collections of related objects are defined
in MIB modules. MIB modules are written using a subset of Abstract in MIB modules. MIB modules are written using a subset of Abstract
Syntax Notation One (ASN.1) [1] termed the Structure of Management Syntax Notation One (ASN.1) [1] termed the Structure of Management
Information (SMI) [2]. In particular, each object type is named by Information (SMI) [2]. In particular, each object type is named by
an OBJECT IDENTIFIER, an administratively assigned name. The object an OBJECT IDENTIFIER, an administratively assigned name. The object
skipping to change at page 2, line 38 skipping to change at page 2, line 38
Instances of these object types represent attributes of an interface Instances of these object types represent attributes of an interface
to an IEEE 802.12 communications medium. At present, IEEE 802.12 to an IEEE 802.12 communications medium. At present, IEEE 802.12
media are identified by one value of the ifType object in the media are identified by one value of the ifType object in the
Internet-standard MIB: Internet-standard MIB:
ieee80212(55) ieee80212(55)
For this interface, the value of the ifSpecific variable in the MIB- For this interface, the value of the ifSpecific variable in the MIB-
II [5] has the OBJECT IDENTIFIER value: II [5] has the OBJECT IDENTIFIER value:
dot12MIB OBJECT IDENTIFIER ::= { experimental 63 } dot12MIB OBJECT IDENTIFIER ::= { transmission TBD }
The values for the ifType object are defined by the IANAifType
textual convention. The Internet Assigned Number Authority (IANA) is
responsible for the assignment of all Internet numbers, including new
ifType values. Therefore, IANA is responsible for maintaining the
definition of this textual convention. The current definition of the
IANAifType textual convention is available from IANA's World Wide Web
server at:
<<INSERT URL HERE>>
The definitions presented here are based on the IEEE Standard The definitions presented here are based on the IEEE Standard
802.12-1995, [6] Clause 13 "Layer management functions and services", 802.12-1995, [6] Clause 13 "Layer management functions and services",
and Annex C "GDMO Specifications for Demand Priority Managed and Annex C "GDMO Specifications for Demand Priority Managed
Objects". Implementors of these MIB objects should note that the Objects". Implementors of these MIB objects should note that the
IEEE document explicitly describes (in the form of Pascal pseudocode) IEEE document explicitly describes (in the form of Pascal pseudocode)
when, where, and how various MAC attributes are measured. The IEEE when, where, and how various MAC attributes are measured. The IEEE
document also describes the effects of MAC actions that may be document also describes the effects of MAC actions that may be
invoked by manipulating instances of the MIB objects defined here. invoked by manipulating instances of the MIB objects defined here.
skipping to change at page 5, line 27 skipping to change at page 5, line 38
The following table provides specific implementation guidelines for The following table provides specific implementation guidelines for
the interface group objects in the conformance groups listed above. the interface group objects in the conformance groups listed above.
Object Use for an 802.12 Interface Object Use for an 802.12 Interface
ifIndex Each 802.12 interface is represented by an ifIndex Each 802.12 interface is represented by an
ifEntry. Interface tables in this MIB ifEntry. Interface tables in this MIB
module are indexed by ifIndex. module are indexed by ifIndex.
ifDescr Interface description. ifDescr Refer to [7].
ifType The IANA reserved value for 802.12 - 55. ifType The IANA reserved value for 802.12 - 55.
ifMtu The value of ifMtu on an 802.12 interface ifMtu The value of ifMtu on an 802.12 interface
will depend on the type of framing that is will depend on the type of framing that is
in use on that interface. Changing the in use on that interface. Changing the
dot12DesiredFramingType may have the effect dot12DesiredFramingType may have the effect
of changing ifMtu after the next time that of changing ifMtu after the next time that
the interface trains. When the interface trains. When
dot12CurrentFramingType is equal to dot12CurrentFramingType is equal to
skipping to change at page 7, line 29 skipping to change at page 7, line 39
packets addressed to functional addresses. packets addressed to functional addresses.
ifOutBroadcastPkts Refer to [7]. ifOutBroadcastPkts Refer to [7].
ifHCInOctets 64-bit version of ifInOctets. ifHCInOctets 64-bit version of ifInOctets.
ifHCOutOctets 64-bit version of ifOutOctets ifHCOutOctets 64-bit version of ifOutOctets
ifHC*Pkts Not required for 100 MBit interfaces. ifHC*Pkts Not required for 100 MBit interfaces.
Future IEEE 802.12 interfaces which operate Future IEEE 802.12 interfaces which operate
at higher speeds may require implemenation at higher speeds may require implementation
of these counters, but such interfaces are of these counters, but such interfaces are
beyond the scope of this memo. beyond the scope of this memo.
ifLinkUpDownTrapEnable Refer to [7]. Default is 'enabled'. ifLinkUpDownTrapEnable Refer to [7]. Default is 'enabled'.
ifHighSpeed The speed of the interface in millions of ifHighSpeed The speed of the interface in millions of
bits per second. For current 802.12 bits per second. For current 802.12
implementations, this will be equal to 100. implementations, this will be equal to 100.
ifPromiscuousMode Reflects whether the interface has ifPromiscuousMode Reflects whether the interface has
skipping to change at page 8, line 15 skipping to change at page 8, line 24
ifConnectorPresent This will normally be 'true'. ifConnectorPresent This will normally be 'true'.
ifStackHigherLayer Refer to section 3.3.1 ifStackHigherLayer Refer to section 3.3.1
ifStackLowerLayer ifStackLowerLayer
ifStackStatus ifStackStatus
ifRcvAddressAddress Refer to section 3.3.4. ifRcvAddressAddress Refer to section 3.3.4.
ifRcvAddressStatus ifRcvAddressStatus
ifRcvAddressType ifRcvAddressType
3.4. Relation to RFC 1749 3.4. Relation to RFC 1643, RFC 1650, and RFC 1748
An IEEE 802.12 interface can be configured to operate in either
ethernet or token ring framing mode. An IEEE 802.12 interface uses
the frame format for the configured framing mode, but does not use
the media access protocol for ethernet or token ring. Instead, IEEE
802.12 defines its own media access protocol, the Demand Priority
Access Method (DPAM).
There are existing standards-track MIB modules for instrumenting
ethernet-like interfaces and token ring interfaces. At the time of
this writing, they are: STD 50, RFC 1643, "Definitions of Managed
Objects for Ethernet-like Interface Types" [8]; RFC 1650,
"Definitions of Managed Objects for Ethernet-like Interface Types
using SMIv2" [9]; and RFC 1748, "IEEE 802.5 MIB using SMIv2" [10].
These MIB modules are designed to instrument the media access
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 for
IEEE 802.12 interfaces.
3.5. Relation to RFC 1749
When an IEEE 802.12 interface is operating in token ring framing When an IEEE 802.12 interface is operating in token ring framing
mode, and the end node supports token ring source routing, the agent mode, and the end node supports token ring source routing, the agent
should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB
[8] for those interfaces.
3.5. Master Mode Operation [11] for those interfaces.
3.6. Master Mode Operation
In an IEEE 802.12 network, "master" devices act as network In an IEEE 802.12 network, "master" devices act as network
controllers to decide when to grant requesting end-nodes permission controllers to decide when to grant requesting end-nodes permission
to transmit. These master devices may be repeaters, or other active to transmit. These master devices may be repeaters, or other active
controller devices such as switches. controller devices such as switches.
Devices which do not act as network controllers, such as end-nodes or Devices which do not act as network controllers, such as end-nodes or
passive switches, are considered to be operating in "slave" mode. passive switches, are considered to be operating in "slave" mode.
The dot12ControlMode object indicates if the interface is operating The dot12ControlMode object indicates if the interface is operating
in master mode or slave mode. in master mode or slave mode.
3.6. Normal and High Priority Counters 3.7. Normal and High Priority Counters
The IEEE 802.12 interface MIB does not provide normal priority The IEEE 802.12 interface MIB does not provide normal priority
transmit counters. Standardization of normal priority transmit transmit counters. Standardization of normal priority transmit
counters could not be justified -- ifOutUcastPkts, counters could not be justified -- ifOutUcastPkts,
ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets, ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets,
dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets should dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets should
suffice. More precisely, the number of normal priority frames suffice. More precisely, the number of normal priority frames
transmitted can be calculated as: transmitted can be calculated as:
outNormPriorityFrames = ifOutUcastPkts + outNormPriorityFrames = ifOutUcastPkts +
skipping to change at page 9, line 44 skipping to change at page 10, line 27
Also, the total traffic at this interface can be calculated as: Also, the total traffic at this interface can be calculated as:
traffic = dot12InNormPriorityOctets + traffic = dot12InNormPriorityOctets +
dot12InHighPriorityOctets + dot12InHighPriorityOctets +
ifOutOctets ifOutOctets
In other words, the normal priority receive counters were deemed In other words, the normal priority receive counters were deemed
useful, whereas the normal priority transmit counters can be easily useful, whereas the normal priority transmit counters can be easily
calculated from other available counters. calculated from other available counters.
3.7. IEEE 802.12 Training Frames 3.8. IEEE 802.12 Training Frames
Training frames are special MAC frames that are used only during link Training frames are special MAC frames that are used only during link
initialization. Training frames are initially constructed by the initialization. Training frames are initially constructed by the
device at the lower end of a link, which is the slave mode device for device at the lower end of a link, which is the slave mode device for
the link. The training frame format is as follows: the link. The training frame format is as follows:
+----+----+------------+--------------+----------+-----+ +----+----+------------+--------------+----------+-----+
| DA | SA | Req Config | Allow Config | Data | FCS | | DA | SA | Req Config | Allow Config | Data | FCS |
+----+----+------------+--------------+----------+-----+ +----+----+------------+--------------+----------+-----+
skipping to change at page 12, line 6 skipping to change at page 13, line 6
requested configuration and allowed configuration fields. requested configuration and allowed configuration fields.
The data field contains between 594 and 675 octets and is filled in The data field contains between 594 and 675 octets and is filled in
by the training initiator. The first 55 octets may be used for by the training initiator. The first 55 octets may be used for
vendor specific protocol information. The remaining octets are all vendor specific protocol information. The remaining octets are all
zeros. The length of the training frame combined with the zeros. The length of the training frame combined with the
requirement that 24 consecutive training frames be received without requirement that 24 consecutive training frames be received without
error to complete training ensures that marginal links will not error to complete training ensures that marginal links will not
complete training. complete training.
3.8. Mapping of IEEE 802.12 Managed Objects 3.9. Mapping of IEEE 802.12 Managed Objects
The following table lists all the managed objects defined for The following table lists all the managed objects defined for
oEndNode in the IEEE 802.12 Standard, and the corresponding SNMP oEndNode in the IEEE 802.12 Standard, and the corresponding SNMP
objects. objects.
IEEE 802.12 Managed Object Corresponding SNMP Object IEEE 802.12 Managed Object Corresponding SNMP Object
oEndNode oEndNode
.aBroadcastFramesReceived IF-MIB - ifInBroadcastPkts .aBroadcastFramesReceived IF-MIB - ifInBroadcastPkts
.aBroadcastFramesTransmitted IF-MIB - ifOutBroadcastPkts .aBroadcastFramesTransmitted IF-MIB - ifOutBroadcastPkts
skipping to change at page 14, line 10 skipping to change at page 15, line 10
.acDeleteGroupAddress IF-MIB - ifRcvAddressTable .acDeleteGroupAddress IF-MIB - ifRcvAddressTable
.acExecuteSelftest IF-MIB - ifAdminStatus .acExecuteSelftest IF-MIB - ifAdminStatus
.acInitializeMAC dot12Commands: 'reset' .acInitializeMAC dot12Commands: 'reset'
.acOpen dot12Commands: 'open' .acOpen dot12Commands: 'open'
4. Definitions 4. Definitions
DOT12-IF-MIB DEFINITIONS ::= BEGIN DOT12-IF-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
experimental, Counter32, Counter64, OBJECT-TYPE, transmission, Counter32, Counter64, OBJECT-TYPE,
MODULE-IDENTITY MODULE-IDENTITY
FROM SNMPv2-SMI FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
ifIndex ifIndex
FROM IF-MIB; FROM IF-MIB;
dot12MIB MODULE-IDENTITY dot12MIB MODULE-IDENTITY
LAST-UPDATED "9512120227Z" LAST-UPDATED "9602220452Z" -- February 22, 1996
ORGANIZATION "IETF 100VG-AnyLAN MIB Working Group" ORGANIZATION "IETF 100VG-AnyLAN MIB Working Group"
CONTACT-INFO CONTACT-INFO
" John Flick " John Flick
Postal: Hewlett Packard Company Postal: Hewlett Packard Company
8000 Foothills Blvd. M/S 5556 8000 Foothills Blvd. M/S 5556
Roseville, CA 95747-5556 Roseville, CA 95747-5556
Tel: +1 916 785 4018 Tel: +1 916 785 4018
Fax: +1 916 785 3583 Fax: +1 916 785 3583
E-mail: johnf@hprnd.rose.hp.com" E-mail: johnf@hprnd.rose.hp.com"
DESCRIPTION DESCRIPTION
"This MIB module describes objects for "This MIB module describes objects for
managing IEEE 802.12 interfaces." managing IEEE 802.12 interfaces."
::= { experimental 63 } ::= { transmission TBD }
-- move to { transmission 55 }
dot12MIBObjects OBJECT IDENTIFIER ::= { dot12MIB 1 } dot12MIBObjects OBJECT IDENTIFIER ::= { dot12MIB 1 }
dot12ConfigTable OBJECT-TYPE dot12ConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot12ConfigEntry SYNTAX SEQUENCE OF Dot12ConfigEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configuration information for a collection of "Configuration information for a collection of
802.12 interfaces attached to a particular 802.12 interfaces attached to a particular
skipping to change at page 15, line 12 skipping to change at page 16, line 11
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configuration for a particular interface to an "Configuration for a particular interface to an
802.12 medium." 802.12 medium."
INDEX { ifIndex } INDEX { ifIndex }
::= { dot12ConfigTable 1 } ::= { dot12ConfigTable 1 }
Dot12ConfigEntry ::= Dot12ConfigEntry ::=
SEQUENCE { SEQUENCE {
dot12CurrentFramingType INTEGER,
dot12DesiredFramingType INTEGER, dot12DesiredFramingType INTEGER,
dot12FramingCapability INTEGER, dot12FramingCapability INTEGER,
dot12DesiredPromiscStatus INTEGER, dot12DesiredPromiscStatus INTEGER,
dot12TrainingVersion INTEGER, dot12TrainingVersion INTEGER,
dot12LastTrainingConfig OCTET STRING, dot12LastTrainingConfig OCTET STRING,
dot12Commands INTEGER, dot12Commands INTEGER,
dot12Status INTEGER, dot12Status INTEGER,
dot12CurrentFramingType INTEGER,
dot12ControlMode INTEGER dot12ControlMode INTEGER
} }
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 1 }
dot12DesiredFramingType OBJECT-TYPE dot12DesiredFramingType OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
frameType88023(1), frameType88023(1),
frameType88025(2), frameType88025(2),
frameTypeEither(3) frameTypeEither(3)
} }
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The type of framing which will be requested by "The type of framing which will be requested by
skipping to change at page 15, line 45 skipping to change at page 17, line 18
In master mode, this is the framing mode which In master mode, this is the framing mode which
will be granted by the interface. Note that will be granted by the interface. Note that
for a master mode interface, this object must be for a master mode interface, this object must be
equal to 'frameType88023' or 'frameType88025', equal to 'frameType88023' or 'frameType88025',
since a master mode interface cannot grant since a master mode interface cannot grant
'frameTypeEither'." 'frameTypeEither'."
REFERENCE REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1, "IEEE Standard 802.12-1995, 13.2.5.2.1,
aDesiredFramingType." aDesiredFramingType."
::= { dot12ConfigEntry 1 } ::= { dot12ConfigEntry 2 }
dot12FramingCapability OBJECT-TYPE dot12FramingCapability OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
frameType88023(1), frameType88023(1),
frameType88025(2), frameType88025(2),
frameTypeEither(3) frameTypeEither(3)
} }
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The type of framing this interface is capable of "The type of framing this interface is capable of
supporting." supporting."
REFERENCE REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1, "IEEE Standard 802.12-1995, 13.2.5.2.1,
aFramingCapability." aFramingCapability."
::= { dot12ConfigEntry 2 } ::= { dot12ConfigEntry 3 }
dot12DesiredPromiscStatus OBJECT-TYPE dot12DesiredPromiscStatus OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
singleAddressMode(1), singleAddressMode(1),
promiscuousMode(2) promiscuousMode(2)
} }
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object is used to select the promiscuous "This object is used to select the promiscuous
skipping to change at page 16, line 44 skipping to change at page 18, line 17
interface when requested by the lower level interface when requested by the lower level
device. device.
Note that this object indicates the desired mode Note that this object indicates the desired mode
for the next time the interface trains. The for the next time the interface trains. The
currently active mode will be reflected in currently active mode will be reflected in
dot12LastTrainingConfig and in ifPromiscuousMode." dot12LastTrainingConfig and in ifPromiscuousMode."
REFERENCE REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1, "IEEE Standard 802.12-1995, 13.2.5.2.1,
aDesiredPromiscuousStatus." aDesiredPromiscuousStatus."
::= { dot12ConfigEntry 3 } ::= { dot12ConfigEntry 4 }
dot12TrainingVersion OBJECT-TYPE dot12TrainingVersion OBJECT-TYPE
SYNTAX INTEGER (0..7) SYNTAX INTEGER (0..7)
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value that will be used in the version bits "The value that will be used in the version bits
(vvv bits) in training frames on this interface. (vvv bits) in training frames on this interface.
This is the highest version number supported by This is the highest version number supported by
this MAC." this MAC."
REFERENCE REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1, "IEEE Standard 802.12-1995, 13.2.5.2.1,
aMACVersion." aMACVersion."
::= { dot12ConfigEntry 4 } ::= { dot12ConfigEntry 5 }
dot12LastTrainingConfig OBJECT-TYPE dot12LastTrainingConfig OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2)) SYNTAX OCTET STRING (SIZE(2))
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This 16 bit field contains the configuration "This 16 bit field contains the configuration
bits from the most recent error-free training bits from the most recent error-free training
frame received during training on this interface. frame received during training on this interface.
Training request frames are received when in Training request frames are received when in
master mode, while training response frames are master mode, while training response frames are
received in slave mode. On master mode interfaces, received in slave mode. On master mode interfaces,
this object contains the contents of the this object contains the contents of the
requested configuration field of the most recent requested configuration field of the most recent
traing request frame. On slave mode interfaces, training request frame. On slave mode interfaces,
this object contains the contents of the allowed this object contains the contents of the allowed
configuration field of the most recent training configuration field of the most recent training
response frame. The format of the current version response frame. The format of the current version
of this field is described in section 3.7. Please of this field is described in section 3.8. Please
refer to the most recent version of the IEEE refer to the most recent version of the IEEE
802.12 standard for the most up-to-date definition 802.12 standard for the most up-to-date definition
of the format of this object." of the format of this object."
REFERENCE REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1, "IEEE Standard 802.12-1995, 13.2.5.2.1,
aLastTrainingConfig." aLastTrainingConfig."
::= { dot12ConfigEntry 5 } ::= { dot12ConfigEntry 6 }
-- { dot12ConfigEntry 6 } is unassigned
dot12Commands OBJECT-TYPE dot12Commands OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
noOp(1), noOp(1),
open(2), open(2),
reset(3), reset(3),
close(4) close(4)
} }
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
skipping to change at page 20, line 42 skipping to change at page 22, line 13
If training does succeed (dot12Status changes to If training does succeed (dot12Status changes to
'opened'), ifOperStatus will change to 'up'. If 'opened'), ifOperStatus will change to 'up'. If
training does not succeed (dot12Status changes to training does not succeed (dot12Status changes to
'linkFailure' or 'openFailure'), ifOperStatus will 'linkFailure' or 'openFailure'), ifOperStatus will
remain 'down'." remain 'down'."
REFERENCE REFERENCE
"IEEE Standard 802.12-1995, 13.2.5.2.1, "IEEE Standard 802.12-1995, 13.2.5.2.1,
aMACStatus." aMACStatus."
::= { dot12ConfigEntry 8 } ::= { 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 }
dot12ControlMode OBJECT-TYPE dot12ControlMode OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
masterMode(1), masterMode(1),
slaveMode(2), slaveMode(2),
learn(3) learn(3)
} }
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object is used to configure and report "This object is used to configure and report
skipping to change at page 21, line 50 skipping to change at page 22, line 47
Some interfaces do not require network management Some interfaces do not require network management
configuration of this feature and can autosense configuration of this feature and can autosense
whether to use master mode or slave mode. The whether to use master mode or slave mode. The
value 'learn' is used for that purpose. While value 'learn' is used for that purpose. While
autosense is taking place, the value 'learn' is autosense is taking place, the value 'learn' is
returned. returned.
A network management operation which modifies the A network management operation which modifies the
value of dot12ControlMode causes the interface value of dot12ControlMode causes the interface
to retrain." to retrain."
::= { dot12ConfigEntry 10 } ::= { dot12ConfigEntry 9 }
dot12StatTable OBJECT-TYPE dot12StatTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot12StatEntry SYNTAX SEQUENCE OF Dot12StatEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Statistics for a collection of 802.12 interfaces "Statistics for a collection of 802.12 interfaces
attached to a particular system." attached to a particular system."
::= { dot12MIBObjects 2 } ::= { dot12MIBObjects 2 }
skipping to change at page 30, line 14 skipping to change at page 31, line 12
END END
5. Acknowledgements 5. Acknowledgements
This document was produced by the IETF 100VG-AnyLAN Working Group. This document was produced by the IETF 100VG-AnyLAN Working Group.
It is based on the work of IEEE 802.12. It is based on the work of IEEE 802.12.
6. References 6. References
[1] Information processing systems - Open Systems Interconnection - [1] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1), Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International International Organization for Standardization. International
Standard 8824 (December, 1987). Standard 8824 (December, 1987).
[2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
of Management Information for version 2 of the Simple Network S. Waldbusser, "Structure of Management Information for Version
Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon SNMP Research, Inc., Cisco Systems, Inc., Dover Beach
University, April 1993. Consulting, Inc., International Network Services, January 1996.
[3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
Conventions for version 2 of the Simple Network Management S. Waldbusser, "Textual Conventions for Version 2 of the Simple
Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research,
Systems, Dover Beach Consulting, Inc., Carnegie Mellon Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
University, April 1993. International Network Services, January 1996.
[4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
"Conformance Statements for version 2 of the Simple Network S. Waldbusser, "Conformance Statements for Version 2 of the
Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP
Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon Research, Inc., Cisco Systems, Inc., Dover Beach Consulting,
University, April 1993. Inc., International Network Services, January 1996.
[5] McCloghrie, K., and M. Rose, "Management Information Base for [5] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets - MIB-II", STD 17, Network Management of TCP/IP-based internets - MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International, RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991. March 1991.
[6] IEEE, "Demand Priority Access Method, Physical Layer and Repeater [6] IEEE, "Demand Priority Access Method, Physical Layer and
Specifications for 100 Mb/s Operation", IEEE Standard Repeater Specifications for 100 Mb/s Operation", IEEE Standard
802.12-1995" 802.12-1995"
[7] McCloghrie, K., and Kastenholz, F., "Evolution of the Interfaces [7] McCloghrie, K., and Kastenholz, F., "Evolution of the Interfaces
Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software,
January 1994. January 1994.
[8] McCloghrie, K., Baker, F., and Decker, E., "IEEE 802.5 Station [8] Kastenholz, F., "Definitions of Managed Objects for the
Source Routing MIB using SMIv2", RFC 1749, cisco Systems, Inc., Ethernet-like Interface Types", STD 50, RFC 1643, FTP Software,
December, 1994. Inc., July, 1994.
[9] Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types using SMIv2", RFC 1650, FTP
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 Station
Source Routing MIB using SMIv2", RFC 1749, Cisco Systems, Inc.,
December, 1994.
7. Security Considerations 7. Security Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
8. Author's Address 8. Author's Address
John Flick John Flick
Hewlett Packard Company Hewlett Packard Company
8000 Foothills Blvd. M/S 5556 8000 Foothills Blvd. M/S 5556
Roseville, CA 95747-5556 Roseville, CA 95747-5556
Phone: +1 916 785 4018 Phone: +1 916 785 4018
Email: johnf@hprnd.rose.hp.com Email: johnf@hprnd.rose.hp.com
Table of Contents Table of Contents
1. Abstract ................................................... 2 1. Introduction ............................................... 2
2. Object Definitions ......................................... 2 2. Object Definitions ......................................... 2
3. Overview ................................................... 2 3. Overview ................................................... 2
3.1. MAC Addresses ............................................ 3 3.1. MAC Addresses ............................................ 3
3.2. Relation to RFC 1213 ..................................... 3 3.2. Relation to RFC 1213 ..................................... 3
3.3. Relation to RFC 1573 ..................................... 3 3.3. Relation to RFC 1573 ..................................... 3
3.3.1. Layering Model ......................................... 4 3.3.1. Layering Model ......................................... 4
3.3.2. Virtual Circuits ....................................... 4 3.3.2. Virtual Circuits ....................................... 4
3.3.3. ifTestTable ............................................ 4 3.3.3. ifTestTable ............................................ 4
3.3.4. ifRcvAddressTable ...................................... 4 3.3.4. ifRcvAddressTable ...................................... 4
3.3.5. ifPhysAddress .......................................... 4 3.3.5. ifPhysAddress .......................................... 4
3.3.6. Specific Interface MIB Objects ......................... 5 3.3.6. Specific Interface MIB Objects ......................... 5
3.4. Relation to RFC 1749 ..................................... 8 3.4. Relation to RFC 1643, RFC 1650, and RFC 1748 ............. 8
3.5. Master Mode Operation .................................... 8 3.5. Relation to RFC 1749 ..................................... 8
3.6. Normal and High Priority Counters ........................ 8 3.6. Master Mode Operation .................................... 9
3.7. IEEE 802.12 Training Frames .............................. 9 3.7. Normal and High Priority Counters ........................ 9
3.8. Mapping of IEEE 802.12 Managed Objects ................... 12 3.8. IEEE 802.12 Training Frames .............................. 10
4. Definitions ................................................ 14 3.9. Mapping of IEEE 802.12 Managed Objects ................... 13
5. Acknowledgements ........................................... 30 4. Definitions ................................................ 15
6. References ................................................. 30 5. Acknowledgements ........................................... 31
7. Security Considerations .................................... 31 6. References ................................................. 31
8. Author's Address ........................................... 31 7. Security Considerations .................................... 32
8. Author's Address ........................................... 32
 End of changes. 41 change blocks. 
89 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/