📄 rfc1748.txt
字号:
Network Working Group K. McCloghrie
Request for Comments: 1748 E. Decker
Obsoletes: 1743, 1231 cisco Systems, Inc.
Category: Standards Track December 1994
IEEE 802.5 MIB using SMIv2
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Table of Contents
1. Introduction ............................................. 1
2. The SNMPv2 Network Management Framework .................. 2
2.1 Object Definitions ...................................... 2
3. Overview ................................................. 2
3.1 MAC Addresses ........................................... 3
3.2 Relationship to RFC 1213 ................................ 3
3.3 Relationship to RFC 1573 ................................ 3
3.3.1 Layering Model ........................................ 3
3.3.2 Virtual Circuits ...................................... 3
3.3.3 ifTestTable ........................................... 3
3.3.4 ifRcvAddressTable ..................................... 4
3.3.5 ifPhysAddress ......................................... 4
3.3.6 ifType ................................................ 4
4. Definitions .............................................. 4
5. Acknowledgements ......................................... 23
6. References ............................................... 23
Appendix A. Changes from RFC 1231 ........................... 24
Security Considerations ..................................... 24
Authors' Addresses .......................................... 25
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing
subnetworks which use the IEEE 802.5 Token Ring technology described
in 802.5 Token Ring Access Method and Physical Layer Specifications,
IEEE Standard 802.5-1989 [7]. This memo is a replacement for RFC
1231.
McCloghrie & Decker [Page 1]
RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994
2. The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of four major
components. They are:
o RFC 1442 [1] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management.
o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed
objects for the Internet suite of protocols.
o RFC 1445 [3] which defines the administrative and other
architectural aspects of the framework.
o RFC 1448 [4] 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
This memo defines three tables: the 802.5 Interface Table, which
contains state and parameter information which is specific to 802.5
interfaces, the 802.5 Statistics Table, which contains 802.5
interface statistics, and the 802.5 Timer Table, which contains the
values of 802.5-defined timers. A managed system will have one entry
in the 802.5 Interface Table and one entry in the 802.5 Statistics
Table for each of its 802.5 interfaces. The 802.5 Timer Table is
obsolete, but its definition has been retained in this memo for
backward compatibility.
This memo also defines OBJECT IDENTIFIERs, some to identify interface
tests for use with the ifTestTable [6], and some to identify Token
Ring interface Chip Sets.
McCloghrie & Decker [Page 2]
RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994
3.1. MAC Addresses
All representations of MAC addresses in this MIB Module use the
MacAddress textual convention [5] for which the address is in the
"canonical" order defined by IEEE 802.1a, i.e., as if it were
transmitted least significant bit first, even though 802.5 requires
MAC addresses to be transmitted most significant bit first.
16-bit addresses, if needed, are represented by setting their upper 4
octets to all zeros, i.e., AAFF would be represented as 00000000AAFF.
3.2. Relationship to RFC 1213
When this MIB module is used in conjunction with the "old" (i.e.,
pre-RFC 1573) interfaces group, the relationship between an 802.5
interface and an interface in the context of the RFC 1213 is one-
to-one. That is, the value of an ifIndex object instance for an
802.5 interface can be directly used to identify corresponding
instances of the objects defined in this memo.
3.3. Relationship to RFC 1573
RFC 1573, the Interface MIB Evolution, requires that any MIB module
which is an adjunct of the Interface MIB, clarify specific areas
within the Interface MIB. These areas were intentionally left vague
in RFC 1573 to avoid over constraining the MIB module, thereby
precluding management of certain media-types.
Section 3.3 of RFC 1573 enumerates several areas which a media-
specific MIB module must clarify. 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
For the typical usage of this IEEE 802.5 MIB module, there will be no
sub-layers "above" or "below" the 802.5 interface. However, this MIB
module does not preclude such layering.
3.3.2. Virtual Circuits
802.5 does not support virtual circuits.
3.3.3. ifTestTable
This MIB module defines two tests for 802.5 interfaces: Insertion and
Loopback. Implementation of these tests is not required.
McCloghrie & Decker [Page 3]
RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994
3.3.4. ifRcvAddressTable
The ifRcvAddressTable is defined to contains all MAC addresses,
unicast, multicast (group) and broadcast, for which an interface will
receive packets. For 802.5 interfaces, its use includes functional
addresses. The format of the address, contained in
ifRcvAddressAddress, is the same as for ifPhysAddress.
For functional addresses on a particular 802.5 interface, only one
ifRcvAddressTable entry is required. That entry is the one for the
address which has the functional address bit ANDed with the bit mask
of all functional addresses for which the interface will accept
frames.
3.3.5. ifPhysAddress
For an 802.5 interface, ifPhysAddress contains the interface's IEEE
MAC address, stored as an octet string of length 6, in IEEE 802.1a
"canonical" order, i.e., the Group Bit is positioned as the low-order
bit (0x01) of the first octet.
3.3.6. ifType
The objects defined in this memo apply to each interface for which
the ifType has the value:
iso88025-tokenRing(9)
4. Definitions
TOKENRING-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
Counter32, Integer32 FROM SNMPv2-SMI
transmission FROM RFC1213-MIB
MacAddress,TimeStamp FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
dot5 MODULE-IDENTITY
LAST-UPDATED "9410231150Z"
ORGANIZATION "IETF Interfaces MIB Working Group"
CONTACT-INFO
" Keith McCloghrie
Postal: cisco Systems, Inc.
170 West Tasman Drive,
San Jose, CA 95134-1706
McCloghrie & Decker [Page 4]
RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994
US
Phone: +1 408 526 5260
EMail: kzm@cisco.com"
DESCRIPTION
"The MIB module for IEEE Token Ring entities."
::= { transmission 9 }
-- The 802.5 Interface Table
-- This table contains state and parameter information which
-- is specific to 802.5 interfaces. It is mandatory that
-- systems having 802.5 interfaces implement this table in
-- addition to the ifTable (see RFCs 1213 and 1573).
dot5Table OBJECT-TYPE
SYNTAX SEQUENCE OF Dot5Entry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains Token Ring interface
parameters and state variables, one entry
per 802.5 interface."
::= { dot5 1 }
dot5Entry OBJECT-TYPE
SYNTAX Dot5Entry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of Token Ring status and parameter
values for an 802.5 interface."
INDEX { dot5IfIndex }
::= { dot5Table 1 }
Dot5Entry ::= SEQUENCE {
dot5IfIndex Integer32,
dot5Commands INTEGER,
dot5RingStatus INTEGER,
dot5RingState INTEGER,
dot5RingOpenStatus INTEGER,
dot5RingSpeed INTEGER,
dot5UpStream MacAddress,
dot5ActMonParticipate INTEGER,
dot5Functional MacAddress,
dot5LastBeaconSent TimeStamp
}
McCloghrie & Decker [Page 5]
RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994
dot5IfIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of this object identifies the
802.5 interface for which this entry
contains management information. The
value of this object for a particular
interface has the same value as the
ifIndex object, defined in MIB-II for
the same interface."
::= { dot5Entry 1 }
dot5Commands OBJECT-TYPE
SYNTAX INTEGER {
noop(1),
open(2),
reset(3),
close(4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When this object is set to the value of
open(2), the station should go into the
open state. The progress and success of
the open is given by the values of the
objects dot5RingState and
dot5RingOpenStatus.
When this object is set to the value
of reset(3), then the station should do
a reset. On a reset, all MIB counters
should retain their values, if possible.
Other side affects are dependent on the
hardware chip set.
When this object is set to the value
of close(4), the station should go into
the stopped state by removing itself
from the ring.
Setting this object to a value of
noop(1) has no effect.
When read, this object always has a
value of noop(1).
The open(2) and close(4) values
correspond to the up(1) and down(2) values
of MIB-II's ifAdminStatus and ifOperStatus,
i.e., the setting of ifAdminStatus and
McCloghrie & Decker [Page 6]
RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994
dot5Commands affects the values of both
dot5Commands and ifOperStatus."
::= { dot5Entry 2 }
dot5RingStatus OBJECT-TYPE
SYNTAX INTEGER (0..262143)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current interface status which can
be used to diagnose fluctuating problems
that can occur on token rings, after a
station has successfully been added to
the ring.
Before an open is completed, this
object has the value for the 'no status'
condition. The dot5RingState and
dot5RingOpenStatus objects provide for
debugging problems when the station
can not even enter the ring.
The object's value is a sum of
values, one for each currently applicable
condition. The following values are
defined for various conditions:
0 = No Problems detected
32 = Ring Recovery
64 = Single Station
256 = Remove Received
512 = reserved
1024 = Auto-Removal Error
2048 = Lobe Wire Fault
4096 = Transmit Beacon
8192 = Soft Error
16384 = Hard Error
32768 = Signal Loss
131072 = no status, open not completed."
::= { dot5Entry 3 }
dot5RingState OBJECT-TYPE
SYNTAX INTEGER {
opened(1),
closed(2),
opening(3),
closing(4),
openFailure(5),
ringFailure(6)
}
McCloghrie & Decker [Page 7]
RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current interface state with respect
to entering or leaving the ring."
::= { dot5Entry 4 }
dot5RingOpenStatus OBJECT-TYPE
SYNTAX INTEGER {
noOpen(1), -- no open attempted
badParam(2),
lobeFailed(3),
signalLoss(4),
insertionTimeout(5),
ringFailed(6),
beaconing(7),
duplicateMAC(8),
requestFailed(9),
removeReceived(10),
open(11) -- last open successful
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the success, or the
reason for failure, of the station's most
recent attempt to enter the ring."
::= { dot5Entry 5 }
dot5RingSpeed OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
oneMegabit(2),
fourMegabit(3),
sixteenMegabit(4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The ring-speed at the next insertion into
the ring. Note that this may or may not be
different to the current ring-speed which is
given by MIB-II's ifSpeed. For interfaces
which do not support changing ring-speed,
dot5RingSpeed can only be set to its current
value. When dot5RingSpeed has the value
unknown(1), the ring's actual ring-speed is
to be used."
McCloghrie & Decker [Page 8]
RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994
::= { dot5Entry 6 }
dot5UpStream OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The MAC-address of the up stream neighbor
station in the ring."
::= { dot5Entry 7 }
dot5ActMonParticipate OBJECT-TYPE
SYNTAX INTEGER {
true(1),
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -