RFC2668 - Definitions of Managed Objects for IEEE 802.3 Medi

时间:2005-02-16 来源: 作者: 点击:
Network Working Group A. Smith Request for Comments: 2668 Extreme Networks, Inc. Obsoletes: 2239 J. Flick Category: Standards Track Hewlett-Packard Company K. de Graaf Argon Networks D. Romascanu Lucent Technologies D. McMaster Cisco Systems, Inc. K.
  Network Working Group A. Smith
Request for Comments: 2668 Extreme Networks, Inc.
Obsoletes: 2239 J. Flick
Category: Standards Track Hewlett-Packard Company
K. de Graaf
Argon Networks
D. Romascanu
Lucent Technologies
D. McMaster
Cisco Systems, Inc.
K. McCloghrie
Cisco Systems, Inc.
S. Roberts
Farallon Computing, Inc.
August 1999

Definitions of Managed Objects for
IEEE 802.3 Medium Attachment Units (MAUs)

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.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
This memo obsoletes RFC2239, "Definitions of Managed Objects for
IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2". This memo
extends that specification by including management information useful
for the management of 1000 Mb/s MAUs.

Ethernet technology, as defined by the 802.3 Working Group of the
IEEE, continues to evolve, with scalable increases in speed, new
types of cabling and interfaces, and new features. This evolution
may require changes in the managed objects in order to reflect this
new functionality. This document, as with other documents issued by
this working group, reflects a certain stage in the evolution of
Ethernet technology. In the future, this document might be revised,

or new documents might be issued by the Ethernet Interfaces and Hub
MIB Working Group, in order to reflect the evolution of Ethernet
technology.

Table of Contents

1. Introduction ............................................... 2
2. The SNMP Management Framework .............................. 3
3. Overview ................................................... 4
3.1. Relationship to RFC2239 ................................. 4
3.2. Relationship to RFC1515 ................................. 4
3.3. MAU Management ........................................... 4
3.4. Relationship to Other MIBs ............................... 5
3.4.1. Relationship to the Interfaces MIB ..................... 5
3.4.2. Relationship to the 802.3 Repeater MIB ................. 5
3.5. Management of Internal MAUs .............................. 5
4. Definitions ................................................ 6
5. Intellectual Property ...................................... 49
6. Acknowledgements ........................................... 49
7. References ................................................. 50
8. Security Considerations .................................... 52
9. Authors' Addresses ......................................... 53
10. Appendix: Change Log ....................................... 55
11. Full Copyright Statement .................................. 57

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 defines objects for managing IEEE 802.3 Medium
Attachment Units (MAUs).

This memo also includes a MIB module. This MIB module extends the
list of managed objects specified in the earlier version of this MIB:
RFC2239 [21].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [20].

2. The SNMP Management Framework

The SNMP Management Framework presently consists of five major
components:

o An overall architecture, described in RFC2571 [1].

o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
STD 16, RFC1155 [2], STD 16, RFC1212 [3] and RFC1215 [4]. The
second version, called SMIv2, is described in STD 58, RFC2578
[5], STD 58, RFC2579 [6] and STD 58, RFC2580 [7].

o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC1157 [8]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC1901 [9] and RFC
1906 [10]. The third version of the message protocol is called
SNMPv3 and described in RFC1906 [10], RFC2572 [11] and RFC2574
[12].

o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC1157 [8]. A second set of protocol
operations and associated PDU formats is described in RFC1905
[13].

o A set of fundamental applications described in RFC2573 [14] and
the view-based access control mechanism described in RFC2575
[15].

Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.

This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.

3. Overview

3.1. Relationship to RFC2239

This MIB is intended to be a superset of that defined by RFC2239
[21], which will go to historic status. This MIB includes all of the
objects contained in that MIB, plus several new ones which provide
additional capabilities. Implementors are encouraged to support all
applicable conformance groups in order to make the best use of the
new functionality provided by this MIB. The new objects provide
management support for:

o management of 1000 Mb/s devices

o management of PAUSE negotiation

o management of remote fault status

3.2. Relationship to RFC1515

RFC2239 was a replacement for RFC1515 [22], which is now historic.
RFC2239 defined a superset of RFC1515 which contained all of the
objects defined in RFC1515, plus several new ones which provided
additional capabilities. The new objects in RFC2239 provided
management support for:

o management of 100 Mb/s devices

o auto-negotiation on interface MAUs

o jack management

3.3. MAU Management

Instances of these object types represent attributes of an IEEE 802.3
MAU. Several types of MAUs are defined in the IEEE 802.3 CSMA/CD
standard [16]. These MAUs may be connected to IEEE 802.3 repeaters
or to 802.3 (Ethernet-like) interfaces. For convenience this document
refers to these devices as "repeater MAUs" and "interface MAUs."

The definitions presented here are based on Section 30.5, "Layer
Management for 10, 100 & 1000 Mb/s Medium Attachment Units (MAUs)",
and Annex 30A, "GDMO Specifications for 802.3 managed object classes"
of IEEE Std. 802.3, 1998 edition [16]. That specification includes
definitions for 10Mb/s, 100Mb/s and 1000Mb/s devices. This
specification is intended to serve the same purpose: to provide for
management of all types of Ethernet/802.3 MAUs.

3.4. Relationship to Other MIBs

It is assumed that an agent implementing this MIB will also implement
(at least) the 'system' group defined in MIB-II [18]. The following
sections identify other MIBs that such an agent should implement.

3.4.1. Relationship to the Interfaces MIB.

The sections of this document that define interface MAU-related
objects specify an extension to the Interfaces MIB [19]. An agent
implementing these interface-MAU related objects MUST also implement
the relevant groups of Interface MIB. The value of the object
ifMauIfIndex is the same as the value of 'ifIndex' used to
instantiate the interface to which the given MAU is connected.

It is expected that an agent implementing the interface-MAU related
objects in this MIB will also implement the Ethernet-like Interfaces
MIB, [23].

(Note that repeater ports are not represented as interfaces in the
Interface MIB.)

3.4.2. Relationship to the 802.3 Repeater MIB

The section of this document that defines repeater MAU-related
objects specifies an extension to the 802.3 Repeater MIB defined in
[17]. An agent implementing these repeater-MAU related objects MUST
also implement the 802.3 Repeater MIB.

The values of 'rpMauGroupIndex' and 'rpMauPortIndex' used to
instantiate a repeater MAU variable SHALL be the same as the values
of 'rptrPortGroupIndex' and 'rptrPortIndex' used to instantiate the
port to which the given MAU is connected.

3.5. Management of Internal MAUs

In some situations, a MAU can be "internal" -- i.e., its
functionality is implemented entirely within a device. For example,
a managed repeater may contain an internal repeater-MAU and/or an
internal interface-MAU through which management communications
originating on one of the repeater's external ports pass in order to
reach the management agent associated with the repeater. Such
internal MAUs may or may not be managed. If they are managed,
objects describing their attributes should appear in the appropriate
MIB subtree: dot3RpMauBasicGroup for internal repeater-MAUs and
dot3IfMauBasicGroup for internal interface-MAUs.

4. Definitions

MAU-MIB DEFINITIONS ::= BEGIN

IMPORTS
Counter32, Integer32,
OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE,
OBJECT-IDENTITY, mib-2
FROM SNMPv2-SMI
TruthValue, TEXTUAL-CONVENTION
FROM SNMPv2-TC
OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP
FROM SNMPv2-CONF;

mauMod MODULE-IDENTITY
LAST-UPDATED "9908240400Z" -- August 24, 1999
ORGANIZATION "IETF Ethernet Interfaces and Hub MIB
Working Group"
CONTACT-INFO
"WG E-mail: hubmib@hprnd.rose.hp.com
To subscribe: hubmib-request@hprnd.rose.hp.com

Chair: Dan Romascanu
Postal: Lucent Technologies
Atidim Technology Park, Bldg. 3
Tel Aviv 61131
Israel
Tel: +972 3 645 8414, 6458458
Fax: +972 3 648 7146
E-mail: dromasca@lucent.com

Editors: Andrew Smith
Postal: Extreme Networks, Inc.
10460 Bandley Drive
Cupertino, CA 95014
USA
Tel: +1 408 579-2821
E-mail: andrew@extremenetworks.com

John Flick
Postal: Hewlett-Packard Company
8000 Foothills Blvd. M/S 5557
Roseville, CA 95747-5557
USA
Tel: +1 916 785 4018
Fax: +1 916 785 1199
E-mail: johnf@rose.hp.com

Kathryn de Graaf
Postal: Argon Networks
25 Porter Road
Littleton, MA 01460
USA
Tel: +1 978 486 0665 x163
Fax: +1 978 486 9379
E-mail: kdegraaf@argon.com"
DESCRIPTION "Management information for 802.3 MAUs.

The following reference is used throughout
this MIB module:

[IEEE 802.3 Std] refers to
IEEE Std 802.3, 1998 Edition: 'Information
technology - Telecommunications and
information exchange between systems -
Local and metropolitan area networks -
Specific requirements - Part 3: Carrier
sense multiple access with collision
detection (CSMA/CD) access method and
physical layer specifications',
September 1998.

Of particular interest is Clause 30, '10Mb/s,
100Mb/s and 1000Mb/s Management'."

REVISION "9908240400Z" -- August 24, 1999
DESCRIPTION "This version published as RFC2668. Updated
to include support for 1000 Mb/sec
MAUs and flow control negotiation."

REVISION "9710310000Z" -- October 31, 1997
DESCRIPTION "This version published as RFC2239."

REVISION "9309300000Z" -- September 30, 1993
DESCRIPTION "Initial version, published as RFC1515."

::= { snmpDot3MauMgt 6 }

snmpDot3MauMgt OBJECT IDENTIFIER ::= { mib-2 26 }

-- textual conventions

JackType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "Common enumeration values for repeater
and interface MAU jack types."

SYNTAX INTEGER {
other(1),
rj45(2),
rj45S(3), -- rj45 shielded
db9(4),
bnc(5),
fAUI(6), -- female aui
mAUI(7), -- male aui
fiberSC(8),
fiberMIC(9),
fiberST(10),
telco(11),
mtrj(12), -- fiber MT-RJ
hssdc(13) -- fiber channel style-2
}

dot3RpMauBasicGroup
OBJECT IDENTIFIER ::= { snmpDot3MauMgt 1 }
dot3IfMauBasicGroup
OBJECT IDENTIFIER ::= { snmpDot3MauMgt 2 }
dot3BroadMauBasicGroup
OBJECT IDENTIFIER ::= { snmpDot3MauMgt 3 }

dot3IfMauAutoNegGroup
OBJECT IDENTIFIER ::= { snmpDot3MauMgt 5 }

-- object identities for MAU types
-- (see rpMauType and ifMauType for usage)

dot3MauType
OBJECT IDENTIFIER ::= { snmpDot3MauMgt 4 }

dot3MauTypeAUI OBJECT-IDENTITY
STATUS current
DESCRIPTION "no internal MAU, view from AUI"
::= { dot3MauType 1 }

dot3MauType10Base5 OBJECT-IDENTITY
STATUS current
DESCRIPTION "thick coax MAU (per 802.3 section 8)"
::= { dot3MauType 2 }
dot3MauTypeFoirl OBJECT-IDENTITY
STATUS current
DESCRIPTION "FOIRL MAU (per 802.3 section 9.9)"
::= { dot3MauType 3 }

dot3MauType10Base2 OBJECT-IDENTITY
STATUS current

DESCRIPTION "thin coax MAU (per 802.3 section 10)"
::= { dot3MauType 4 }

dot3MauType10BaseT OBJECT-IDENTITY
STATUS current
DESCRIPTION "UTP MAU (per 802.3 section 14).
Note that it is strongly recommended that
agents return either dot3MauType10BaseTHD or
dot3MauType10BaseTFD if the duplex mode is
known. However, management applications should
be prepared to receive this MAU type value from
older agent implementations."
::= { dot3MauType 5 }

dot3MauType10BaseFP OBJECT-IDENTITY
STATUS current
DESCRIPTION "passive fiber MAU (per 802.3 section 16)"
::= { dot3MauType 6 }

dot3MauType10BaseFB OBJECT-IDENTITY
STATUS current
DESCRIPTION "sync fiber MAU (per 802.3 section 17)"
::= { dot3MauType 7 }

dot3MauType10BaseFL OBJECT-IDENTITY
STATUS current
DESCRIPTION "async fiber MAU (per 802.3 section 18)
Note that it is strongly recommended that
agents return either dot3MauType10BaseFLHD or
dot3MauType10BaseFLFD if the duplex mode is
known. However, management applications should
be prepared to receive this MAU type value from
older agent implementations."
::= { dot3MauType 8 }

dot3MauType10Broad36 OBJECT-IDENTITY
STATUS current
DESCRIPTION "broadband DTE MAU (per 802.3 section 11).
Note that 10BROAD36 MAUs can be attached to
interfaces but not to repeaters."
::= { dot3MauType 9 }
------ new since RFC1515:
dot3MauType10BaseTHD OBJECT-IDENTITY
STATUS current
DESCRIPTION "UTP MAU (per 802.3 section 14), half duplex
mode"
::= { dot3MauType 10 }

dot3MauType10BaseTFD OBJECT-IDENTITY
STATUS current
DESCRIPTION "UTP MAU (per 802.3 section 14), full duplex
mode"
::= { dot3MauType 11 }

dot3MauType10BaseFLHD OBJECT-IDENTITY
STATUS current
DESCRIPTION "async fiber MAU (per 802.3 section 18), half
duplex mode"
::= { dot3MauType 12 }

dot3MauType10BaseFLFD OBJECT-IDENTITY
STATUS current
DESCRIPTION "async fiber MAU (per 802.3 section 18), full
duplex mode"
::= { dot3MauType 13 }

dot3MauType100BaseT4 OBJECT-IDENTITY
STATUS current
DESCRIPTION "4 pair categ. 3 UTP (per 802.3 section 23)"
::= { dot3MauType 14 }

dot3MauType100BaseTXHD OBJECT-IDENTITY
STATUS current
DESCRIPTION "2 pair categ. 5 UTP (per 802.3 section 25),
half duplex mode"
::= { dot3MauType 15 }

dot3MauType100BaseTXFD OBJECT-IDENTITY
STATUS current
DESCRIPTION "2 pair categ. 5 UTP (per 802.3 section 25),
full duplex mode"
::= { dot3MauType 16 }

dot3MauType100BaseFXHD OBJECT-IDENTITY
STATUS current
DESCRIPTION "X fiber over PMT (per 802.3 section 26), half
duplex mode"
::= { dot3MauType 17 }
dot3MauType100BaseFXFD OBJECT-IDENTITY
STATUS current
DESCRIPTION "X fiber over PMT (per 802.3 section 26), full
duplex mode"
::= { dot3MauType 18 }

dot3MauType100BaseT2HD OBJECT-IDENTITY
STATUS current

DESCRIPTION "2 pair categ. 3 UTP (per 802.3 section 32),
half duplex mode"
::= { dot3MauType 19 }

dot3MauType100BaseT2FD OBJECT-IDENTITY
STATUS current
DESCRIPTION "2 pair categ. 3 UTP (per 802.3 section 32),
full duplex mode"
::= { dot3MauType 20 }

------ new since RFC2239:

dot3MauType1000BaseXHD OBJECT-IDENTITY
STATUS current
DESCRIPTION "PCS/PMA (per 802.3 section 36), unknown PMD,
half duplex mode"
::= { dot3MauType 21 }

dot3MauType1000BaseXFD OBJECT-IDENTITY
STATUS current
DESCRIPTION "PCS/PMA (per 802.3 section 36), unknown PMD,
full duplex mode"
::= { dot3MauType 22 }

dot3MauType1000BaseLXHD OBJECT-IDENTITY
STATUS current
DESCRIPTION "Fiber over long-wavelength laser (per 802.3
section 38), half duplex mode"
::= { dot3MauType 23 }

dot3MauType1000BaseLXFD OBJECT-IDENTITY
STATUS current
DESCRIPTION "Fiber over long-wavelength laser (per 802.3
section 38), full duplex mode"
::= { dot3MauType 24 }

dot3MauType1000BaseSXHD OBJECT-IDENTITY
STATUS current
DESCRIPTION "Fiber over short-wavelength laser (per 802.3
section 38), half duplex mode"
::= { dot3MauType 25 }

dot3MauType1000BaseSXFD OBJECT-IDENTITY
STATUS current
DESCRIPTION "Fiber over short-wavelength laser (per 802.3
section 38), full duplex mode"
::= { dot3MauType 26 }

dot3MauType1000BaseCXHD OBJECT-IDENTITY
STATUS current
DESCRIPTION "Copper over 150-Ohm balanced cable (per 802.3
section 39), half duplex mode"
::= { dot3MauType 27 }

dot3MauType1000BaseCXFD OBJECT-IDENTITY
STATUS current
DESCRIPTION "Copper over 150-Ohm balanced cable (per 802.3
section 39), full duplex mode"
::= { dot3MauType 28 }

dot3MauType1000BaseTHD OBJECT-IDENTITY
STATUS current
DESCRIPTION "Four-pair Category 5 UTP (per 802.3 section
40), half duplex mode"
::= { dot3MauType 29 }

dot3MauType1000BaseTFD OBJECT-IDENTITY
STATUS current
DESCRIPTION "Four-pair Category 5 UTP (per 802.3 section
40), full duplex mode"
::= { dot3MauType 30 }

--
-- The Basic Repeater MAU Table
--

rpMauTable OBJECT-TYPE
SYNTAX SEQUENCE OF RpMauEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Table of descriptive and status information
about the MAU(s) attached to the ports of a
repeater."
::= { dot3RpMauBasicGroup 1 }

rpMauEntry OBJECT-TYPE
SYNTAX RpMauEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the table, containing information
about a single MAU."
INDEX { rpMauGroupIndex,
rpMauPortIndex,
rpMauIndex
}
::= { rpMauTable 1 }

RpMauEntry ::=
SEQUENCE {
rpMauGroupIndex Integer32,
rpMauPortIndex Integer32,
rpMauIndex Integer32,
rpMauType OBJECT IDENTIFIER,
rpMauStatus INTEGER,
rpMauMediaAvailable INTEGER,
rpMauMediaAvailableStateExits Counter32,
rpMauJabberState INTEGER,
rpMauJabberingStateEnters Counter32,
rpMauFalseCarriers Counter32
}

rpMauGroupIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This variable uniquely identifies the group
containing the port to which the MAU described
by this entry is connected.

Note: In practice, a group will generally be
a field-replaceable unit (i.e., module, card,
or board) that can fit in the physical system
enclosure, and the group number will correspond
to a number marked on the physical enclosure.

The group denoted by a particular value of this
object is the same as the group denoted by the
same value of rptrGroupIndex."
REFERENCE "Reference RFC2108, rptrGroupIndex."
::= { rpMauEntry 1 }

rpMauPortIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This variable uniquely identifies the repeater
port within group rpMauGroupIndex to which the
MAU described by this entry is connected."
REFERENCE "Reference RFC2108, rptrPortIndex."
::= { rpMauEntry 2 }

rpMauIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current

DESCRIPTION "This variable uniquely identifies the MAU
described by this entry from among other
MAUs connected to the same port
(rpMauPortIndex)."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.1, aMAUID."
::= { rpMauEntry 3 }

rpMauType OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object identifies the MAU type. An
initial set of MAU types are defined above. The
assignment of OBJECT IDENTIFIERs to new types of
MAUs is managed by the IANA. If the MAU type is
unknown, the object identifier

unknownMauType OBJECT IDENTIFIER ::= { 0 0 }

is returned. Note that unknownMauType is a
syntactically valid object identifier, and any
conformant implementation of ASN.1 and the BER
must be able to generate and recognize this
value."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.2, aMAUType."
::= { rpMauEntry 4 }

rpMauStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),
unknown(2),
operational(3),
standby(4),
shutdown(5),
reset(6)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION "The current state of the MAU. This object MAY
be implemented as a read-only object by those
agents and MAUs that do not implement software
control of the MAU state. Some agents may not
support setting the value of this object to some
of the enumerated values.

The value other(1) is returned if the MAU is in
a state other than one of the states 2 through
6.

The value unknown(2) is returned when the MAU's
true state is unknown; for example, when it is
being initialized.

A MAU in the operational(3) state is fully
functional, operates, and passes signals to its
attached DTE or repeater port in accordance to
its specification.

A MAU in standby(4) state forces DI and CI to
idle and the media transmitter to idle or fault,
if supported. Standby(4) mode only applies to
link type MAUs. The state of
rpMauMediaAvailable is unaffected.

A MAU in shutdown(5) state assumes the same
condition on DI, CI, and the media transmitter
as though it were powered down or not connected.
The MAU MAY return other(1) value for the
rpMauJabberState and rpMauMediaAvailable objects
when it is in this state. For an AUI, this
state will remove power from the AUI.

Setting this variable to the value reset(6)
resets the MAU in the same manner as a
power-off, power-on cycle of at least one-half
second would. The agent is not required to
return the value reset (6).

Setting this variable to the value
operational(3), standby(4), or shutdown(5)
causes the MAU to assume the respective state
except that setting a mixing-type MAU or an AUI
to standby(4) will cause the MAU to enter the
shutdown state."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.7, aMAUAdminState,
30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1,
acResetMAU."
::= { rpMauEntry 5 }

rpMauMediaAvailable OBJECT-TYPE
SYNTAX INTEGER {
other(1),
unknown(2),
available(3),
notAvailable(4),
remoteFault(5),
invalidSignal(6),

remoteJabber(7),
remoteLinkLoss(8),
remoteTest(9),
offline(10),
autoNegError(11)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "If the MAU is a link or fiber type (FOIRL,
10BASE-T, 10BASE-F) then this is equivalent to
the link test fail state/low light function.
For an AUI or a coax (including broadband) MAU
this indicates whether or not loopback is
detected on the DI circuit. The value of this
attribute persists between packets for MAU types
AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP.

The value other(1) is returned if the
mediaAvailable state is not one of 2 through 11.

The value unknown(2) is returned when the MAU's
true state is unknown; for example, when it is
being initialized. At power-up or following a
reset, the value of this attribute will be
unknown for AUI, coax, and 10BASE-FP MAUs. For
these MAUs loopback will be tested on each
transmission during which no collision is
detected. If DI is receiving input when DO
returns to IDL after a transmission and there
has been no collision during the transmission
then loopback will be detected. The value of
this attribute will only change during
non-collided transmissions for AUI, coax, and
10BASE-FP MAUs.

For 100Mbps and 1000Mbps MAUs, the enumerations
match the states within the respective link
integrity state diagrams, fig 32-16, 23-12 and
24-15 of sections 32, 23 and 24 of [16]. Any
MAU which implements management of
auto-negotiation will map remote fault
indication to remote fault.

The value available(3) indicates that the link,
light, or loopback is normal. The value
notAvailable(4) indicates link loss, low light,
or no loopback.

The value remoteFault(5) indicates that a fault
has been detected at the remote end of the link.
This value applies to 10BASE-FB, 100BASE-T4 Far
End Fault Indication and non-specified remote
faults from a system running auto-negotiation.
The values remoteJabber(7), remoteLinkLoss(8),
and remoteTest(9) SHOULD be used instead of
remoteFault(5) where the reason for remote fault
is identified in the remote signaling protocol.

The value invalidSignal(6) indicates that an
invalid signal has been received from the other
end of the link. InvalidSignal(6) applies only
to MAUs of type 10BASE-FB.

Where an IEEE Std 802.3u-1995 clause 22 MII
is present, a logic one in the remote fault bit
(reference section 22.2.4.2.8 of that document)
maps to the value remoteFault(5), and a logic
zero in the link status bit (reference section
22.2.4.2.10 of that document) maps to the value
notAvailable(4). The value notAvailable(4)
takes precedence over the value remoteFault(5).

Any MAU that implements management of clause 37
Auto-Negotiation will map the received Remote
Fault (RF1 and RF2) bit values for Offline to
offline(10), Link Failure to remoteFault(5) and
Auto-Negotiation Error to autoNegError(11)."

REFERENCE "[IEEE 802.3 Std], 30.5.1.1.4, aMediaAvailable."
::= { rpMauEntry 6 }

rpMauMediaAvailableStateExits OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of the number of times that
rpMauMediaAvailable for this MAU instance leaves
the state available(3).

Discontinuities in the value of this counter can
occur at re-initialization of the management
system, and at other times as indicated by the
value of rptrMonitorPortLastChange."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.5,
aLoseMediaCounter.
RFC2108, rptrMonitorPortLastChange"

::= { rpMauEntry 7 }

rpMauJabberState OBJECT-TYPE
SYNTAX INTEGER {
other(1),
unknown(2),
noJabber(3),
jabbering(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The value other(1) is returned if the jabber
state is not 2, 3, or 4. The agent MUST always
return other(1) for MAU type dot3MauTypeAUI.

The value unknown(2) is returned when the MAU's
true state is unknown; for example, when it is
being initialized.

If the MAU is not jabbering the agent returns
noJabber(3). This is the 'normal' state.

If the MAU is in jabber state the agent returns
the jabbering(4) value."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.6,
aJabber.jabberFlag."
::= { rpMauEntry 8 }

rpMauJabberingStateEnters OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of the number of times that
mauJabberState for this MAU instance enters the
state jabbering(4). For MAUs of type
dot3MauTypeAUI, dot3MauType100BaseT4,
dot3MauType100BaseTX, dot3MauType100BaseFX and
all 1000Mbps types, this counter will always
indicate zero.

Discontinuities in the value of this counter
can occur at re-initialization of the
management system, and at other times as
indicated by the value of
rptrMonitorPortLastChange."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.6,
aJabber.jabberCounter.
RFC2108, rptrMonitorPortLastChange"

::= { rpMauEntry 9 }

rpMauFalseCarriers OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of the number of false carrier events
during IDLE in 100BASE-X links. This counter
does not increment at the symbol rate. It can
increment after a valid carrier completion at a
maximum rate of once per 100 ms until the next
carrier event.

This counter increments only for MAUs of type
dot3MauType100BaseT4, dot3MauType100BaseTX, and
dot3MauType100BaseFX and all 1000Mbps types.
For all other MAU types, this counter will
always indicate zero.

The approximate minimum time for rollover of
this counter is 7.4 hours.

Discontinuities in the value of this counter can
occur at re-initialization of the management
system, and at other times as indicated by the
value of rptrMonitorPortLastChange."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.10, aFalseCarriers.
RFC2108, rptrMonitorPortLastChange"
::= { rpMauEntry 10 }

-- The rpJackTable applies to MAUs attached to repeaters
-- which have one or more external jacks (connectors).

rpJackTable OBJECT-TYPE
SYNTAX SEQUENCE OF RpJackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Information about the external jacks attached
to MAUs attached to the ports of a repeater."
::= { dot3RpMauBasicGroup 2 }

rpJackEntry OBJECT-TYPE
SYNTAX RpJackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the table, containing information
about a particular jack."
INDEX { rpMauGroupIndex,

rpMauPortIndex,
rpMauIndex,
rpJackIndex
}
::= { rpJackTable 1 }

RpJackEntry ::=
SEQUENCE {
rpJackIndex Integer32,
rpJackType JackType
}

rpJackIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This variable uniquely identifies the jack
described by this entry from among other jacks
attached to the same MAU (rpMauIndex)."
::= { rpJackEntry 1 }

rpJackType OBJECT-TYPE
SYNTAX JackType
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The jack connector type, as it appears on the
outside of the system."
::= { rpJackEntry 2 }

--
-- The Basic Interface MAU Table
--

ifMauTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfMauEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Table of descriptive and status information
about MAU(s) attached to an interface."
::= { dot3IfMauBasicGroup 1 }

ifMauEntry OBJECT-TYPE
SYNTAX IfMauEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the table, containing information
about a single MAU."
INDEX { ifMauIfIndex,

ifMauIndex
}
::= { ifMauTable 1 }

IfMauEntry ::=
SEQUENCE {
ifMauIfIndex Integer32,
ifMauIndex Integer32,
ifMauType OBJECT IDENTIFIER,
ifMauStatus INTEGER,
ifMauMediaAvailable INTEGER,
ifMauMediaAvailableStateExits Counter32,
ifMauJabberState INTEGER,
ifMauJabberingStateEnters Counter32,
ifMauFalseCarriers Counter32,
ifMauTypeList Integer32,
ifMauDefaultType OBJECT IDENTIFIER,
ifMauAutoNegSupported TruthValue,
ifMauTypeListBits BITS
}

ifMauIfIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This variable uniquely identifies the interface
to which the MAU described by this entry is
connected."
REFERENCE "RFC1213, ifIndex"
::= { ifMauEntry 1 }

ifMauIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This variable uniquely identifies the MAU
described by this entry from among other MAUs
connected to the same interface (ifMauIfIndex)."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.1, aMAUID."
::= { ifMauEntry 2 }

ifMauType OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object identifies the MAU type. An
initial set of MAU types are defined above. The
assignment of OBJECT IDENTIFIERs to new types of

MAUs is managed by the IANA. If the MAU type is
unknown, the object identifier

unknownMauType OBJECT IDENTIFIER ::= { 0 0 }

is returned. Note that unknownMauType is a
syntactically valid object identifier, and any
conformant implementation of ASN.1 and the BER
must be able to generate and recognize this
value.

This object represents the operational type of
the MAU, as determined by either (1) the result
of the auto-negotiation function or (2) if
auto-negotiation is not enabled or is not
implemented for this MAU, by the value of the
object ifMauDefaultType. In case (2), a set to
the object ifMauDefaultType will force the MAU
into the new operating mode."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.2, aMAUType."
::= { ifMauEntry 3 }

ifMauStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),
unknown(2),
operational(3),
standby(4),
shutdown(5),
reset(6)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION "The current state of the MAU. This object MAY
be implemented as a read-only object by those
agents and MAUs that do not implement software
control of the MAU state. Some agents may not
support setting the value of this object to some
of the enumerated values.

The value other(1) is returned if the MAU is in
a state other than one of the states 2 through
6.

The value unknown(2) is returned when the MAU's
true state is unknown; for example, when it is
being initialized.

A MAU in the operational(3) state is fully
functional, operates, and passes signals to its
attached DTE or repeater port in accordance to
its specification.

A MAU in standby(4) state forces DI and CI to
idle and the media transmitter to idle or fault,
if supported. Standby(4) mode only applies to
link type MAUs. The state of
ifMauMediaAvailable is unaffected.

A MAU in shutdown(5) state assumes the same
condition on DI, CI, and the media transmitter
as though it were powered down or not connected.
The MAU MAY return other(1) value for the
ifMauJabberState and ifMauMediaAvailable objects
when it is in this state. For an AUI, this
state will remove power from the AUI.

Setting this variable to the value reset(6)
resets the MAU in the same manner as a
power-off, power-on cycle of at least one-half
second would. The agent is not required to
return the value reset (6).

Setting this variable to the value
operational(3), standby(4), or shutdown(5)
causes the MAU to assume the respective state
except that setting a mixing-type MAU or an AUI
to standby(4) will cause the MAU to enter the
shutdown state."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.7, aMAUAdminState,
30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1,
acResetMAU."
::= { ifMauEntry 4 }
ifMauMediaAvailable OBJECT-TYPE
SYNTAX INTEGER {
other(1),
unknown(2),
available(3),
notAvailable(4),
remoteFault(5),
invalidSignal(6),
remoteJabber(7),
remoteLinkLoss(8),
remoteTest(9),
offline(10),
autoNegError(11)

}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "If the MAU is a link or fiber type (FOIRL,
10BASE-T, 10BASE-F) then this is equivalent to
the link test fail state/low light function.
For an AUI or a coax (including broadband) MAU
this indicates whether or not loopback is
detected on the DI circuit. The value of this
attribute persists between packets for MAU types
AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP.

The value other(1) is returned if the
mediaAvailable state is not one of 2 through 11.

The value unknown(2) is returned when the MAU's
true state is unknown; for example, when it is
being initialized. At power-up or following a
reset, the value of this attribute will be
unknown for AUI, coax, and 10BASE-FP MAUs. For
these MAUs loopback will be tested on each
transmission during which no collision is
detected. If DI is receiving input when DO
returns to IDL after a transmission and there
has been no collision during the transmission
then loopback will be detected. The value of
this attribute will only change during
non-collided transmissions for AUI, coax, and
10BASE-FP MAUs.

For 100Mbps and 1000Mbps MAUs, the enumerations
match the states within the respective link
integrity state diagrams, fig 32-16, 23-12 and
24-15 of sections 32, 23 and 24 of [16]. Any
MAU which implements management of
auto-negotiation will map remote fault
indication to remote fault.

The value available(3) indicates that the link,
light, or loopback is normal. The value
notAvailable(4) indicates link loss, low light,
or no loopback.

The value remoteFault(5) indicates that a fault
has been detected at the remote end of the link.
This value applies to 10BASE-FB, 100BASE-T4 Far
End Fault Indication and non-specified remote
faults from a system running auto-negotiation.

The values remoteJabber(7), remoteLinkLoss(8),
and remoteTest(9) SHOULD be used instead of
remoteFault(5) where the reason for remote fault
is identified in the remote signaling protocol.

The value invalidSignal(6) indicates that an
invalid signal has been received from the other
end of the link. InvalidSignal(6) applies only
to MAUs of type 10BASE-FB.

Where an IEEE Std 802.3u-1995 clause 22 MII
is present, a logic one in the remote fault bit
(reference section 22.2.4.2.8 of that document)
maps to the value remoteFault(5), and a logic
zero in the link status bit (reference section
22.2.4.2.10 of that document) maps to the value
notAvailable(4). The value notAvailable(4)
takes precedence over the value remoteFault(5).

Any MAU that implements management of clause 37
Auto-Negotiation will map the received RF1 and
RF2 bit values for Offline to offline(10), Link
Failure to remoteFault(5) and Auto-Negotiation
Error to autoNegError(11)."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.4, aMediaAvailable."
::= { ifMauEntry 5 }

ifMauMediaAvailableStateExits OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of the number of times that
ifMauMediaAvailable for this MAU instance leaves
the state available(3).
Discontinuities in the value of this counter can
occur at re-initialization of the management
system, and at other times as indicated by the
value of ifCounterDiscontinuityTime."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.5,
aLoseMediaCounter.
RFC2233, ifCounterDiscontinuityTime."
::= { ifMauEntry 6 }

ifMauJabberState OBJECT-TYPE
SYNTAX INTEGER {
other(1),
unknown(2),
noJabber(3),

jabbering(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The value other(1) is returned if the jabber
state is not 2, 3, or 4. The agent MUST always
return other(1) for MAU type dot3MauTypeAUI.

The value unknown(2) is returned when the MAU's
true state is unknown; for example, when it is
being initialized.

If the MAU is not jabbering the agent returns
noJabber(3). This is the 'normal' state.

If the MAU is in jabber state the agent returns
the jabbering(4) value."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.6,
aJabber.jabberFlag."
::= { ifMauEntry 7 }

ifMauJabberingStateEnters OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of the number of times that
mauJabberState for this MAU instance enters the
state jabbering(4). This counter will always
indicate zero for MAUs of type dot1MauTypeAUI
and those of speeds above 10Mbps.

Discontinuities in the value of this counter can
occur at re-initialization of the management
system, and at other times as indicated by the
value of ifCounterDiscontinuityTime."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.6,
aJabber.jabberCounter.
RFC2233, ifCounterDiscontinuityTime."
::= { ifMauEntry 8 }

ifMauFalseCarriers OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of the number of false carrier events
during IDLE in 100BASE-X and 1000BASE-X links.

For all other MAU types, this counter will

always indicate zero. This counter does not
increment at the symbol rate.

It can increment after a valid carrier
completion at a maximum rate of once per 100 ms
for 100BASE-X and once per 10us for 1000BASE-X
until the next CarrierEvent.

Discontinuities in the value of this counter can
occur at re-initialization of the management
system, and at other times as indicated by the
value of ifCounterDiscontinuityTime."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.10, aFalseCarriers.
RFC2233, ifCounterDiscontinuityTime."
::= { ifMauEntry 9 }

ifMauTypeList OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION "********* THIS OBJECT IS DEPRECATED **********

A value that uniquely identifies the set of
possible IEEE 802.3 types that the MAU could be.
The value is a sum which initially takes the
value zero. Then, for each type capability of
this MAU, 2 raised to the power noted below is
added to the sum. For example, a MAU which has
the capability to be only 10BASE-T would have a
value of 512 (2**9). In contrast, a MAU which
supports both 10Base-T (full duplex) and
100BASE-TX (full duplex) would have a value of
((2**11) + (2**16)) or 67584.

The powers of 2 assigned to the capabilities are
these:

Power Capability
0 other or unknown
1 AUI
2 10BASE-5
3 FOIRL
4 10BASE-2
5 10BASE-T duplex mode unknown
6 10BASE-FP
7 10BASE-FB
8 10BASE-FL duplex mode unknown
9 10BROAD36

10 10BASE-T half duplex mode
11 10BASE-T full duplex mode
12 10BASE-FL half duplex mode
13 10BASE-FL full duplex mode
14 100BASE-T4
15 100BASE-TX half duplex mode
16 100BASE-TX full duplex mode
17 100BASE-FX half duplex mode
18 100BASE-FX full duplex mode
19 100BASE-T2 half duplex mode
20 100BASE-T2 full duplex mode

If auto-negotiation is present on this MAU, this
object will map to ifMauAutoNegCapability.

This object has been deprecated in favour of
ifMauTypeListBits."
::= { ifMauEntry 10 }

ifMauDefaultType OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-write
STATUS current
DESCRIPTION "This object identifies the default
administrative baseband MAU type, to be used in
conjunction with the operational MAU type
denoted by ifMauType.

The set of possible values for this object is
the same as the set defined for the ifMauType
object.

This object represents the
administratively-configured type of the MAU. If
auto-negotiation is not enabled or is not
implemented for this MAU, the value of this
object determines the operational type of the
MAU. In this case, a set to this object will
force the MAU into the specified operating mode.

If auto-negotiation is implemented and enabled
for this MAU, the operational type of the MAU
is determined by auto-negotiation, and the value
of this object denotes the type to which the MAU
will automatically revert if/when
auto-negotiation is later disabled.

NOTE TO IMPLEMENTORS: It may be necessary to

provide for underlying hardware implementations
which do not follow the exact behavior specified
above. In particular, when
ifMauAutoNegAdminStatus transitions from enabled
to disabled, the agent implementation MUST
ensure that the operational type of the MAU (as
reported by ifMauType) correctly transitions to
the value specified by this object, rather than
continuing to operate at the value earlier
determined by the auto-negotiation function."
REFERENCE "[IEEE 802.3 Std], 30.5.1.1.1, aMAUID, and
22.2.4.1.4."
::= { ifMauEntry 11 }

ifMauAutoNegSupported OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object indicates whether or not
auto-negotiation is supported on this MAU."
::= { ifMauEntry 12 }
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容