Network Working Group M. Squire
Request for Comments: 4878 Hatteras Networks
Category: Standards Track June 2007
Definitions and Managed Objects for
Operations, Administration, and Maintenance (OAM) Functions on
Ethernet-Like Interfaces
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 IETF Trust (2007).
Abstract
This document defines objects for managing Operations,
Administration, and Maintenance (OAM) capabilities on Ethernet-like
interfaces conformant to the Ethernet OAM functionality defined in
the Ethernet in the First Mile (EFM) clauses of the Ethernet
standards. The Ethernet OAM functionality is complementary to the
Simple Network Management Protocol (SNMP) in that it is focused on a
small set of link-specific functions for directly connected Ethernet
interfaces. This document defines objects for controlling those link
OAM functions and for providing results and status of the OAM
functions to management entities.
Squire Standards Track [Page 1]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
Table of Contents
1. Introduction ....................................................2
2. The Internet-Standard Management Framework ......................2
3. Overview ........................................................3
3.1. Remote Fault Indication ....................................4
3.2. Link Monitoring ............................................4
3.3. Remote Loopback ............................................5
3.4. Ethernet OAM Protocol Data Units ...........................5
4. Relation to the Other MIB Modules ...............................5
4.1. Relation to Other MIB Modules ..............................5
4.2. Relation to Other EFM MIB Modules ..........................6
4.3. Mapping of IEEE 802.3ah Managed Objects ....................6
5. MIB Structure ...................................................7
6. MIB Definition ..................................................8
7. Security Considerations ........................................47
8. IANA Considerations ............................................49
9. References .....................................................49
9.1. Normative References ......................................49
9.2. Informative References ....................................50
10. Acknowledgments ...............................................51
1. Introduction
The IEEE 802.3ah Ethernet in the First Mile (EFM) taskforce added new
management capabilities to Ethernet-like interfaces. These
management capabilities were introduced to provide some basic Ordered
Aggregate (OA) function on Ethernet media. The defined functionality
includes discovery, error signaling, loopback, and link monitoring.
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community
to manage these new Ethernet interface capabilities.
Conventions Used in This Document
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 RFC 2119 [RFC2119].
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Squire Standards Track [Page 2]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
3. Overview
Ethernet networks have evolved over the past 30 years from simple
LANs to a variety of other applications, including wide-area
networks. To address some of these emerging markets, the IEEE
802.3ah taskforce defined additional clauses in [802.3ah] for the
IEEE 802.3 standard [802.3-2002] to better address Ethernet
deployments in the public-access network. Although Ethernet-access
deployments were the primary motivation for the taskforce activity,
the results of the taskforce are not strictly limited to that
application. Ethernet OAM can be implemented on Ethernet links that
are not EFM.
The Ethernet in the First Mile (EFM) taskforce was focused on four
somewhat independent objectives to better address Ethernet access
deployments: optics, copper, Ethernet passive optical networks
(Ethernet PON, or EPON), and operations, administration, and
maintenance (OAM). The optics sub-taskforce developed new optical
physical layers that better served the long-reach outside plant
networks typically found in the access network, including developing
physical layers that operate up to 20 Km and supporting the
environmental conditions of access deployments. The copper sub-
taskforce developed two new physical layers that run Ethernet
natively over existing twisted pair wires that have been supporting
voice services for decades. The EPON sub-taskforce developed a new
point-to-multipoint Ethernet physical layer, utilizing Ethernet
framing natively over a time-division multiple-access (TDMA)
infrastructure. The OAM sub-taskforce introduced some basic
management functionality into an Ethernet link to better monitor and
maintain Ethernet networks in geographically disparate networks.
This document defines the management objects necessary to integrate
Ethernet OAM functionality into the SNMP management framework.
Ethernet OAM is composed of a core set of functions and a set of
optional functional groups. The mandatory functions include
discovery operations (determining if the other end of the link is OA
capable and what OAM functions it supports), state machine
implementation, and some critical event flows. The optional
functional groups are for (a) link events, (b) remote loopback, and
(c) variable retrieval and response. Each optional functional group
is controlled by a separate MIB table(s).
Squire Standards Track [Page 3]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
Ethernet OAM is complementary with SNMP management in that it
provides some basic management functions at layer two, rather than
using layer three and above as required by SNMP over an IP
infrastructure. Ethernet OAM provides single-hop functionality in
that it works only between two directly connected Ethernet stations.
SNMP can be used to manage the Ethernet OAM interactions of one
Ethernet station with another.
Ethernet OAM has three functional objectives, which are detailed in
the next three sections. The definition of a basic Ethernet OA
protocol data unit is given in Section 3.4.
3.1. Remote Fault Indication
Remote fault indication provides a mechanism for one end of an
Ethernet link to signal the other end that the receive path is non-
operational. Some Ethernet physical layers offer mechanisms to
signal this condition at the physical layer. Ethernet OAM added a
mechanism so that some Ethernet physical layers can operate in
unidirectional mode, allowing frames to be transmitted in one
direction even when the other direction is non-operational.
Traditionally, Ethernet PHYs do not allow frame transmission in one
direction if the other direction is not operational. Using this
mode, Ethernet OAM allows frame-based signaling of remote fault
conditions while still not allowing higher-layer applications to be
aware of the unidirectional capability. This document includes
mechanisms for capturing that fault information and reflecting such
information in objects and notifications within the SNMP management
framework.
3.2. Link Monitoring
Ethernet OAM includes event signaling capability so that one end of
an Ethernet link can indicate the occurrence of certain important
events to the other end of the link. This happens via layer two
protocols. This document defines methods for incorporating the
occurrence of these layer two events, both at the local end and far
end of the link, into the SNMP management framework.
Ethernet OAM also includes mechanisms for one Ethernet station to
query another directly connected Ethernet station about the status of
its Ethernet interface variables and status. This document does not
include mechanisms for controlling how one Ethernet endpoint may use
this functionality to query the status or statistics of a peer
Ethernet entity.
Squire Standards Track [Page 4]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
3.3. Remote Loopback
Remote loopback is a link state where the peer Ethernet entity echoes
every received packet (without modifications) back onto the link.
Remote loopback is intrusive in that the other end of the link is not
forwarding traffic from higher layers out over the link. This
document defines objects controlling loopback operation and reading
the status of the loopback state.
3.4. Ethernet OAM Protocol Data Units
An Ethernet OAM protocol data unit is a valid Ethernet frame with a
destination Media Access Control (MAC) address equal to the reserved
MAC address for Slow Protocols (See 43B of [802.3ah]), a lengthOrType
field equal to the reserved type for Slow Protocols, and a Slow
Protocols subtype equal to that of the subtype reserved for Ethernet
OAM.
OAMPDU is used throughout this document as an abbreviation for
Ethernet OAM protocol data unit. OAMPDUs are the mechanism by which
two directly connected Ethernet interfaces exchange OA information.
4. Relation to the Other MIB Modules
The definitions presented here are based on Clauses 30 and 57 of
[802.3ah]. Note that these clauses describe many of these variables
and their effects on the MAC layer. In some cases, there is a one-
to-one relationship between an object in this document and an object
in the Clause 30 MIB of [802.3ah]. In other cases, the objects of
this document reflect a more complex entity and are reflected by more
than one object in the Clause 30 MIB of [802.3ah].
4.1. Relation to Other MIB Modules
The objects defined in this document manage OAM functionality
introduced in [802.3ah] These objects do not overlap with the
interfaces MIB [RFC2863], the Ethernet-like interfaces MIB [RFC3635],
or any other MIB currently used to manage various aspects of an
Ethernet interface. The objects defined here are defined for
Ethernet-like interfaces only and use the same ifIndex as the
associated Ethernet interface. Ethernet OAM can be implemented on
any Ethernet-like interface.
Squire Standards Track [Page 5]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
4.2. Relation to Other EFM MIB Modules
The Ethernet OAM functionality and MIB Module is independent of the
other functionality and MIB Modules derived from [802.3ah] for copper
[802.3ah-copper] and EPON [802.3ah-epon]. Ethernet OAM may be
implemented (or not) on the new EFM interface types, just as it can
on any other Ethernet interface.
4.3. Mapping of IEEE 802.3ah Managed Objects
This section contains the mapping between managed objects defined in
[802.3ah] Clause 30, and managed objects defined in this document.
IEEE 802.3 Managed Object Corresponding SNMP object
oOA
.aOAMID IF-MIB ifIndex
.aOAMAdminState dot3OamAdminState
.aOAMMode dot3OamMode
.aOAMDiscoveryState dot3OamOperStatus
.aOAMRemoteMACAddress dot3OamPeerMacAddress
.aOAMLocalConfiguration dot3OamFunctionsSupported
.aOAMRemoteConfiguration dot3OamPeerFunctionsSupported,
dot3OamPeerMode
.aOAMLocalPDUConfiguration dot3OamMaxOamPduSize
.aOAMRemotePDUConfiguration dot3OamPeerMaxOamPduSize
.aOAMLocalFlagsField dot3OamOperStatus,
dot3OamEventLogEntry
.aOAMRemoteFlagsField dot3OamOperStatus,
dot3OamEventLogEntry
.aOAMLocalRevision dot3OamConfigRevision
.aOAMRemoteRevision dot3OamPeerConfigRevision
.aOAMLocalState dot3OamLoopbackStatus
.aOAMRemoteState dot3OamLoopbackStatus
.aOAMRemoteVendorOUI dot3OamPeerVendorOui
.aOAMRemoteVendorSpecificInfo dot3OamPeerVendorInfo
.aOAMUnsupportedCodesTx dot3OamUnsupportedCodesTx
.aOAMUnsupportedCodesRx dot3OamUnsupportedCodesRx
.aOAMInformationTx dot3OamInformationTx
.aOAMInformationRx dot3OamInformationRx
.aOAMUniqueEventNotificationTx dot3OamUniqueEventNotificationTx
.aOAMUniqueEventNotificationRx dot3OamUniqueEventNotificationRx
.aOAMDuplicateEventNotificationTx
dot3OamDuplicateEventNotificationTx
.aOAMDuplicateEventNotificationRx
dot3OamDuplicateEventNotificationRx
.aOAMLoopbackControlTx dot3OamLoopbackControlTx
Squire Standards Track [Page 6]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
.aOAMLoopbackControlRx dot3OamLoopbackControlRx
.aOAMVariableRequestTx dot3OamVariableRequestTx
.aOAMVariableRequestRx dot3OamVariableRequestRx
.aOAMVariableResponseTx dot3OamVariableResponseTx
.aOAMVariableResponseRx dot3OamVariableResponseRx
.aOAMOrganizationSpecificTx dot3OamOrgSpecificTx
.aOAMOrganizationSpecificRx dot3OamOrgSpecificTx
.aOAMLocalErrSymPeriodConfig dot3OamErrSymPeriodWindow,
dot3OamErrSymPeriodThreshold
.aOAMLocalErrSymPeriodEvent dot3OamEventLogEntry
.aOAMLocalErrFrameConfig dot3OamErrFrameWindow,
dot3OamErrFrameThreshold
.aOAMLocalErrFrameEvent dot3OamEventLogEntry
.aOAMLocalErrFramePeriodConfig dot3OamErrFramePeriodWindow,
dot3OamErrFramePeriodThreshold
.aOAMLocalErrFramePeriodEvent dot3OamEventLogEntry
.aOAMLocalErrFrameSecsSummaryConfig
dot3OamErrFrameSecsSummaryWindow,
dot3OamErrFrameSecssummaryThreshold
.aOAMLocalErrFrameSecsSummaryEvent
dot3OamEventLogEntry
.aOAMRemoteErrSymPeriodEvent dot3OamEventLogEntry
.aOAMRemoteErrFrameEvent dot3OamEventLogEntry
.aOAMRemoteErrFramePeriodEvent dot3OamEventLogEntry
.aOAMRemoteErrFrameSecsSummaryEvent
dot3OamEventLogEntry
.aFramesLostDueToOAmError dot3OamFramesLostDueToOam
.acOAMAdminControl dot3OamAdminState
There are no IEEE 802.3ah managed objects that are not reflected in
this MIB Module in some manner.
5. MIB Structure
The Ethernet OAM MIB objects of this memo focus on the OA
capabilities introduced in [802.3ah]. The MIB objects are
partitioned into six different MIB groups.
The dot3OamTable group manages the primary OAM objects of the
Ethernet interface. This group controls the state and status of OA
as well as the mode in which it operates.
The dot3OamPeerTable maintains the current information on the status
and configuration of the peer OAM entity on the Ethernet interface.
Managed information includes the capabilities and function available
on the peer OAM entity.
Squire Standards Track [Page 7]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
The dot3OamLoopbackTable manages the loopback function introduced in
[802.3ah]. This table controls enabling and disabling loopback, as
well as indicating the loopback status of Ethernet OAM on this
interface.
The dot3OamStatsTable maintains statistics on the number and type of
Ethernet OAM frames being transmitted and received on the Ethernet
interface.
The dot3OamEventConfigTable defines the objects for managing the
event notification capability available in Ethernet OAM. With
Ethernet OAM, one device may send notifications to its peer devices
whenever an important event happens on the local device. This table
provides management of which events result in notifications via
Ethernet OAM notifications and/or via SNMP notifications.
The dot3OamEventLogTable manages the current status of local and
remote events detected via Ethernet OAM. This table is updated
whenever local events are detected by Ethernet OAM or whenever
Ethernet OAM Event Notifications are received from the peer OA
entity.
There are two notifications defined to report Ethernet OAM events
(one for threshold crossing events, one for non-threshold crossing
events). Both notifications are contained within the same
conformance group.
6. MIB Definition
DOT3-OAM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2, OBJECT-TYPE, Counter32, Unsigned32,
Integer32, NOTIFICATION-TYPE
FROM SNMPv2-SMI
-- from [RFC2578]
TEXTUAL-CONVENTION, MacAddress, TimeStamp, TruthValue
FROM SNMPv2-TC
-- from [RFC2579]
CounterBasedGauge64
FROM HCNUM-TC
-- from [RFC2856]
ifIndex
FROM IF-MIB
-- from [RFC2863]
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF;
Squire Standards Track [Page 8]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
- from [RFC2580]
dot3OamMIB MODULE-IDENTITY
LAST-UPDATED "200706140000Z" -- June 14,2007"
ORGANIZATION
"IETF Ethernet Interfaces and Hub MIB Working Group"
CONTACT-INFO
"WG Charter:
http://www.ietf.org/html.charters/hubmib-charter.html
Mailing lists:
General Discussion: hubmib@ietf.org
To Subscribe: hubmib-requests@ietf.org
In Body: subscribe your_email_address
Chair: Bert Wijnen
Alcatel-Lucent
Email: bwijnen at alcatel-lucent dot com
Editor: Matt Squire
Hatteras Networks
E-mail: msquire at hatterasnetworks dot com
"
DESCRIPTION
"The MIB module for managing the new Ethernet OAM features
introduced by the Ethernet in the First Mile taskforce (IEEE
802.3ah). The functionality presented here is based on IEEE
802.3ah [802.3ah], released in October, 2004. [802.3ah] was
prepared as an addendum to the standing version of IEEE 802.3
[802.3-2002]. Since then, [802.3ah] has been
merged into the base IEEE 802.3 specification in [802.3-2005].
In particular, this MIB focuses on the new OAM functions
introduced in Clause 57 of [802.3ah]. The OAM functionality
of Clause 57 is controlled by new management attributes
introduced in Clause 30 of [802.3ah]. The OAM functions are
not specific to any particular Ethernet physical layer, and
can be generically applied to any Ethernet interface of
[802.3-2002].
An Ethernet OAM protocol data unit is a valid Ethernet frame
with a destination MAC address equal to the reserved MAC
address for Slow Protocols (See 43B of [802.3ah]), a
lengthOrType field equal to the reserved type for Slow
Protocols, and a Slow Protocols subtype equal to that of the
subtype reserved for Ethernet OAM. OAMPDU is used throughout
this document as an abbreviation for Ethernet OAM protocol
data unit.
The following reference is used throughout this MIB module:
Squire Standards Track [Page 9]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
[802.3ah] refers to:
IEEE Std 802.3ah-2004: 'Draft amendment to -
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
- Media Access Control Parameters, Physical Layers and
Management Parameters for subscriber access networks',
October 2004.
[802.3-2002] refers to:
IEEE Std 802.3-2002:
'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
- Media Access Control Parameters, Physical Layers and
Management Parameters for subscriber access networks',
March 2002.
[802.3-2005] refers to:
IEEE Std 802.3-2005:
'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
- Media Access Control Parameters, Physical Layers and
Management Parameters for subscriber access networks',
December 2005.
[802-2001] refers to:
'IEEE Standard for LAN/MAN (Local Area
Network/Metropolitan Area Network): Overview and
Architecture', IEEE 802, June 2001.
Copyright (c) The IETF Trust (2007). This version of
this MIB module is part of RFC 4878; See the RFC itself for
full legal notices. "
REVISION "200706140000Z" -- June 14, 2007"
DESCRIPTION "Initial version, published as RFC 4878."
::= { mib-2 158 }
-
- Sections of the Ethernet OAM MIB
Squire Standards Track [Page 10]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
-
dot3OamNotifications OBJECT IDENTIFIER ::= { dot3OamMIB 0 }
dot3OamObjects OBJECT IDENTIFIER ::= { dot3OamMIB 1 }
dot3OamConformance OBJECT IDENTIFIER ::= { dot3OamMIB 2 }
-
- Textual conventions for the OAM MIB
-
EightOTwoOui ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"24-bit Organizationally Unique Identifier. Information on
OUIs can be found in IEEE 802-2001 [802-2001], Clause 9."
SYNTAX OCTET STRING(SIZE(3))
-
*
–
– Ethernet OAM Control group
–
dot3OamTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OamEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the primary controls and status for the
OAM capabilities of an Ethernet-like interface. There will be
one row in this table for each Ethernet-like interface in the
system that supports the OAM functions defined in [802.3ah].
"
::= { dot3OamObjects 1 }
dot3OamEntry OBJECT-TYPE
SYNTAX Dot3OamEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table that contains information on the
Ethernet OAM function for a single Ethernet like interface.
Entries in the table are created automatically for each
interface supporting Ethernet OAM. The status of the row
entry can be determined from dot3OamOperStatus.
A dot3OamEntry is indexed in the dot3OamTable by the ifIndex
object of the Interfaces MIB.
"
INDEX { ifIndex }
::= { dot3OamTable 1 }
Squire Standards Track [Page 11]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
Dot3OamEntry ::=
SEQUENCE {
dot3OamAdminState INTEGER,
dot3OamOperStatus INTEGER,
dot3OamMode INTEGER,
dot3OamMaxOamPduSize Unsigned32,
dot3OamConfigRevision Unsigned32,
dot3OamFunctionsSupported BITS
}
dot3OamAdminState OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to provision the default administrative
OAM mode for this interface. This object represents the
desired state of OAM for this interface.
The dot3OamAdminState always starts in the disabled(2) state
until an explicit management action or configuration
information retained by the system causes a transition to the
enabled(1) state. When enabled(1), Ethernet OAM will attempt
to operate over this interface.
"
REFERENCE "[802.3ah], 30.3.6.1.2"
::= { dot3OamEntry 1 }
dot3OamOperStatus OBJECT-TYPE
SYNTAX INTEGER {
disabled(1),
linkFault(2),
passiveWait(3),
activeSendLocal(4),
sendLocalAndRemote(5),
sendLocalAndRemoteOk(6),
oamPeeringLocallyRejected(7),
oamPeeringRemotelyRejected(8),
operational(9),
nonOperHalfDuplex(10)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"At initialization and failure conditions, two OAM entities on
Squire Standards Track [Page 12]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
the same full-duplex Ethernet link begin a discovery phase to
determine what OAM capabilities may be used on that link. The
progress of this initialization is controlled by the OA
sublayer.
This value is always disabled(1) if OAM is disabled on this
interface via the dot3OamAdminState.
If the link has detected a fault and is transmitting OAMPDUs
with a link fault indication, the value is linkFault(2).
Also, if the interface is not operational (ifOperStatus is
not up(1)), linkFault(2) is returned. Note that the object
ifOperStatus may not be up(1) as a result of link failure or
administrative action (ifAdminState being down(2) or
testing(3)).
The passiveWait(3) state is returned only by OAM entities in
passive mode (dot3OamMode) and reflects the state in which the
OAM entity is waiting to see if the peer device is OA
capable. The activeSendLocal(4) value is used by active mode
devices (dot3OamMode) and reflects the OAM entity actively
trying to discover whether the peer has OAM capability but has
not yet made that determination.
The state sendLocalAndRemote(5) reflects that the local OA
entity has discovered the peer but has not yet accepted or
rejected the configuration of the peer. The local device can,
for whatever reason, decide that the peer device is
unacceptable and decline OAM peering. If the local OAM entity
rejects the peer OAM entity, the state becomes
oamPeeringLocallyRejected(7). If the OAM peering is allowed
by the local device, the state moves to
sendLocalAndRemoteOk(6). Note that both the
sendLocalAndRemote(5) and oamPeeringLocallyRejected(7) states
fall within the state SEND_LOCAL_REMOTE of the Discovery state
diagram [802.3ah, Figure 57-5], with the difference being
whether the local OAM client has actively rejected the peering
or has just not indicated any decision yet. Whether a peering
decision has been made is indicated via the local flags field
in the OAMPDU (reflected in the aOAMLocalFlagsField of
30.3.6.1.10).
If the remote OAM entity rejects the peering, the state
becomes oamPeeringRemotelyRejected(8). Note that both the
sendLocalAndRemoteOk(6) and oamPeeringRemotelyRejected(8)
states fall within the state SEND_LOCAL_REMOTE_OK of the
Discovery state diagram [802.3ah, Figure 57-5], with the
difference being whether the remote OAM client has rejected
Squire Standards Track [Page 13]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
the peering or has just not yet decided. This is indicated
via the remote flags field in the OAMPDU (reflected in the
aOAMRemoteFlagsField of 30.3.6.1.11).
When the local OAM entity learns that both it and the remote
OAM entity have accepted the peering, the state moves to
operational(9) corresponding to the SEND_ANY state of the
Discovery state diagram [802.3ah, Figure 57-5].
Since Ethernet OAM functions are not designed to work
completely over half-duplex interfaces, the value
nonOperHalfDuplex(10) is returned whenever Ethernet OAM is
enabled (dot3OamAdminState is enabled(1)), but the interface
is in half-duplex operation.
"
REFERENCE "[802.3ah], 30.3.6.1.4, 30.3.6.1.10, 30.3.6.1.11"
::= { dot3OamEntry 2 }
dot3OamMode OBJECT-TYPE
SYNTAX INTEGER {
passive(1),
active(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object configures the mode of OAM operation for this
Ethernet-like interface. OAM on Ethernet interfaces may be in
'active' mode or 'passive' mode. These two modes differ in
that active mode provides additional capabilities to initiate
monitoring activities with the remote OAM peer entity, while
passive mode generally waits for the peer to initiate OA
actions with it. As an example, an active OAM entity can put
the remote OAM entity in a loopback state, where a passive OA
entity cannot.
The default value of dot3OamMode is dependent on the type of
system on which this Ethernet-like interface resides. The
default value should be 'active(2)' unless it is known that
this system should take on a subservient role to the other
device connected over this interface.
Changing this value results in incrementing the configuration
revision field of locally generated OAMPDUs (30.3.6.1.12) and
potentially re-doing the OAM discovery process if the
dot3OamOperStatus was already operational(9).
"
REFERENCE "[802.3ah], 30.3.6.1.3"
Squire Standards Track [Page 14]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
::= { dot3OamEntry 3 }
dot3OamMaxOamPduSize OBJECT-TYPE
SYNTAX Unsigned32 (64..1518)
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The largest OAMPDU that the OAM entity supports. OA
entities exchange maximum OAMPDU sizes and negotiate to use
the smaller of the two maximum OAMPDU sizes between the peers.
This value is determined by the local implementation.
"
REFERENCE "[802.3ah], 30.3.6.1.8"
::= { dot3OamEntry 4 }
dot3OamConfigRevision OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The configuration revision of the OAM entity as reflected in
the latest OAMPDU sent by the OAM entity. The config revision
is used by OAM entities to indicate that configuration changes
have occurred, which might require the peer OAM entity to
re-evaluate whether OAM peering is allowed.
"
REFERENCE "[802.3ah], 30.3.6.1.12"
::= { dot3OamEntry 5 }
dot3OamFunctionsSupported OBJECT-TYPE
SYNTAX BITS {
unidirectionalSupport (0),
loopbackSupport(1),
eventSupport(2),
variableSupport(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The OAM functions supported on this Ethernet-like interface.
OAM consists of separate functional sets beyond the basic
discovery process that is always required. These functional
groups can be supported independently by any implementation.
These values are communicated to the peer via the local
configuration field of Information OAMPDUs.
Setting 'unidirectionalSupport(0)' indicates that the OA
Squire Standards Track [Page 15]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
entity supports the transmission of OAMPDUs on links that are
operating in unidirectional mode (traffic flowing in one
direction only). Setting 'loopbackSupport(1)' indicates that
the OAM entity can initiate and respond to loopback commands.
Setting 'eventSupport(2)' indicates that the OAM entity can
send and receive Event Notification OAMPDUs. Setting
'variableSupport(3)' indicates that the OAM entity can send
and receive Variable Request and Response OAMPDUs.
"
REFERENCE "[802.3ah], 30.3.6.1.6"
::= { dot3OamEntry 6 }
– *
-
- Ethernet OAM Peer group
-
dot3OamPeerTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OamPeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains information about the OAM peer for a
particular Ethernet-like interface. OAM entities communicate
with a single OAM peer entity on Ethernet links on which OA
is enabled and operating properly. There is one entry in this
table for each entry in the dot3OamTable for which information
on the peer OAM entity is available.
"
::= { dot3OamObjects 2 }
dot3OamPeerEntry OBJECT-TYPE
SYNTAX Dot3OamPeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table containing information on the peer OA
entity for a single Ethernet-like interface.
Note that there is at most one OAM peer for each Ethernet-like
interface. Entries are automatically created when information
about the OAM peer entity becomes available, and automatically
deleted when the OAM peer entity is no longer in
communication. Peer information is not available when
dot3OamOperStatus is disabled(1), linkFault(2),
passiveWait(3), activeSendLocal(4), or nonOperHalfDuplex(10).
"
INDEX { ifIndex }
Squire Standards Track [Page 16]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
::= { dot3OamPeerTable 1 }
Dot3OamPeerEntry ::=
SEQUENCE {
dot3OamPeerMacAddress MacAddress,
dot3OamPeerVendorOui EightOTwoOui,
dot3OamPeerVendorInfo Unsigned32,
dot3OamPeerMode INTEGER,
dot3OamPeerMaxOamPduSize Unsigned32,
dot3OamPeerConfigRevision Unsigned32,
dot3OamPeerFunctionsSupported BITS
}
dot3OamPeerMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The MAC address of the peer OAM entity. The MAC address is
derived from the most recently received OAMPDU.
"
REFERENCE "[802.3ah], 30.3.6.1.5."
::= { dot3OamPeerEntry 1 }
dot3OamPeerVendorOui OBJECT-TYPE
SYNTAX EightOTwoOui
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The OUI of the OAM peer as reflected in the latest
Information OAMPDU received with a Local Information TLV. The
OUI can be used to identify the vendor of the remote OA
entity. This value is initialized to three octets of zero
before any Local Information TLV is received.
"
REFERENCE "[802.3ah], 30.3.6.1.16."
::= { dot3OamPeerEntry 2 }
dot3OamPeerVendorInfo OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Vendor Info of the OAM peer as reflected in the latest
Information OAMPDU received with a Local Information TLV.
The semantics of the Vendor Information field is proprietary
and specific to the vendor (identified by the
dot3OamPeerVendorOui). This information could, for example,
Squire Standards Track [Page 17]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
be used to identify a specific product or product family.
This value is initialized to zero before any Local
Information TLV is received.
"
REFERENCE "[802.3ah], 30.3.6.1.17."
::= { dot3OamPeerEntry 3 }
dot3OamPeerMode OBJECT-TYPE
SYNTAX INTEGER {
passive(1),
active(2),
unknown(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The mode of the OAM peer as reflected in the latest
Information OAMPDU received with a Local Information TLV. The
mode of the peer can be determined from the Configuration
field in the Local Information TLV of the last Information
OAMPDU received from the peer. The value is unknown(3)
whenever no Local Information TLV has been received. The
values of active(2) and passive(1) are returned when a Local
Information TLV has been received indicating that the peer is
in active or passive mode, respectively.
"
REFERENCE "[802.3ah], 30.3.6.1.7."
::= { dot3OamPeerEntry 4 }
dot3OamPeerMaxOamPduSize OBJECT-TYPE
SYNTAX Unsigned32 (0 | 64..1518)
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum size of OAMPDU supported by the peer as reflected
in the latest Information OAMPDU received with a Local
Information TLV. Ethernet OAM on this interface must not use
OAMPDUs that exceed this size. The maximum OAMPDU size can be
determined from the PDU Configuration field of the Local
Information TLV of the last Information OAMPDU received from
the peer. A value of zero is returned if no Local Information
TLV has been received. Otherwise, the value of the OAM peer's
maximum OAMPDU size is returned in this value.
"
REFERENCE "[802.3ah], 30.3.6.1.9."
::= { dot3OamPeerEntry 5 }
Squire Standards Track [Page 18]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
dot3OamPeerConfigRevision OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The configuration revision of the OAM peer as reflected in
the latest OAMPDU. This attribute is changed by the peer
whenever it has a local configuration change for Ethernet OA
on this interface. The configuration revision can be
determined from the Revision field of the Local Information
TLV of the most recently received Information OAMPDU with
a Local Information TLV. A value of zero is returned if
no Local Information TLV has been received.
"
REFERENCE "[802.3ah], 30.3.6.1.13."
::= { dot3OamPeerEntry 6 }
dot3OamPeerFunctionsSupported OBJECT-TYPE
SYNTAX BITS {
unidirectionalSupport (0),
loopbackSupport(1),
eventSupport(2),
variableSupport(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The OAM functions supported on this Ethernet-like interface.
OAM consists of separate functionality sets above the basic
discovery process. This value indicates the capabilities of
the peer OAM entity with respect to these functions. This
value is initialized so all bits are clear.
If unidirectionalSupport(0) is set, then the peer OAM entity
supports sending OAM frames on Ethernet interfaces when the
receive path is known to be inoperable. If
loopbackSupport(1) is set, then the peer OAM entity can send
and receive OAM loopback commands. If eventSupport(2) is set,
then the peer OAM entity can send and receive event OAMPDUs to
signal various error conditions. If variableSupport(3) is
set, then the peer OAM entity can send and receive variable
requests to monitor the attribute value as described in Clause
57 of [802.3ah].
The capabilities of the OAM peer can be determined from the
configuration field of the Local Information TLV of the most
recently received Information OAMPDU with a Local Information
TLV. All zeros are returned if no Local Information TLV has
Squire Standards Track [Page 19]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
yet been received.
"
REFERENCE "[802.3ah], REFERENCE 30.3.6.1.7."
::= { dot3OamPeerEntry 7 }
-
*
–
– Ethernet OAM Loopback group
–
dot3OamLoopbackTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OamLoopbackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains controls for the loopback state of the
local link as well as indicates the status of the loopback
function. There is one entry in this table for each entry in
dot3OamTable that supports loopback functionality (where
dot3OamFunctionsSupported includes the loopbackSupport bit
set).
Loopback can be used to place the remote OAM entity in a state
where every received frame (except OAMPDUs) is echoed back
over the same interface on which they were received. In this
state, at the remote entity, 'normal' traffic is disabled as
only the looped back frames are transmitted on the interface.
Loopback is thus an intrusive operation that prohibits normal
data flow and should be used accordingly.
"
::= { dot3OamObjects 3 }
dot3OamLoopbackEntry OBJECT-TYPE
SYNTAX Dot3OamLoopbackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table, containing information on the loopback
status for a single Ethernet-like interface. Entries in the
table are automatically created whenever the local OAM entity
supports loopback capabilities. The loopback status on the
interface can be determined from the dot3OamLoopbackStatus
object.
"
INDEX { ifIndex }
::= { dot3OamLoopbackTable 1 }
Dot3OamLoopbackEntry ::=
Squire Standards Track [Page 20]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
SEQUENCE {
dot3OamLoopbackStatus INTEGER,
dot3OamLoopbackIgnoreRx INTEGER
}
dot3OamLoopbackStatus OBJECT-TYPE
SYNTAX INTEGER {
– all values, except where noted, can be read
– but cannot be written
noLoopback (1),
– initiatingLoopback can be read or written
initiatingLoopback (2),
remoteLoopback (3),
– terminatingLoopback can be read or written
terminatingLoopback (4),
localLoopback (5),
unknown (6)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The loopback status of the OAM entity. This status is
determined by a combination of the local parser and
multiplexer states, the remote parser and multiplexer states,
as well as by the actions of the local OAM client. When
operating in normal mode with no loopback in progress, the
status reads noLoopback(1).
The values initiatingLoopback(2) and terminatingLoopback(4)
can be read or written. The other values can only be read -
they can never be written. Writing initiatingLoopback causes
the local OAM entity to start the loopback process with its
peer. This value can only be written when the status is
noLoopback(1). Writing the value initiatingLoopback(2) in any
other state has no effect. When in remoteLoopback(3), writing
terminatingLoopback(4) causes the local OAM entity to initiate
the termination of the loopback state. Writing
terminatingLoopack(4) in any other state has no effect.
If the OAM client initiates a loopback and has sent a
Loopback OAMPDU and is waiting for a response, where the local
parser and multiplexer states are DISCARD (see [802.3ah,
57.2.11.1]), the status is 'initiatingLoopback'. In this
case, the local OAM entity has yet to receive any
acknowledgment that the remote OAM entity has received its
loopback command request.
Squire Standards Track [Page 21]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
If the local OAM client knows that the remote OAM entity is in
loopback mode (via the remote state information as described
in [802.3ah, 57.2.11.1, 30.3.6.1.15]), the status is
remoteLoopback(3). If the local OAM client is in the process
of terminating the remote loopback [802.3ah, 57.2.11.3,
30.3.6.1.14] with its local multiplexer and parser states in
DISCARD, the status is terminatingLoopback(4). If the remote
OAM client has put the local OAM entity in loopback mode as
indicated by its local parser state, the status is
localLoopback(5).
The unknown(6) status indicates that the parser and
multiplexer combination is unexpected. This status may be
returned if the OAM loopback is in a transition state but
should not persist.
The values of this attribute correspond to the following
values of the local and remote parser and multiplexer states.
value LclPrsr LclMux RmtPrsr RmtMux
noLoopback FWD FWD FWD FWD
initLoopback DISCARD DISCARD FWD FWD
rmtLoopback DISCARD FWD LPBK DISCARD
tmtngLoopback DISCARD DISCARD LPBK DISCARD
lclLoopback LPBK DISCARD DISCARD FWD
unknown * any other combination
*
"
REFERENCE "[802.3ah], REFERENCE 57.2.11, 30.3.61.14,
30.3.6.1.15"
::= { dot3OamLoopbackEntry 1 }
dot3OamLoopbackIgnoreRx OBJECT-TYPE
SYNTAX INTEGER { ignore(1), process(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Since OAM loopback is a disruptive operation (user traffic
does not pass), this attribute provides a mechanism to provide
controls over whether received OAM loopback commands are
processed or ignored. When the value is ignore(1), received
loopback commands are ignored. When the value is process(2),
OAM loopback commands are processed. The default value is to
ignore loopback commands (ignore(1)).
"
REFERENCE "[802.3ah], REFERENCE 57.2.11, 30.3.61.14,
30.3.6.1.15"
::= { dot3OamLoopbackEntry 2 }
Squire Standards Track [Page 22]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
– *
-
- Ethernet OAM Statistics group
-
dot3OamStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OamStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains statistics for the OAM function on a
particular Ethernet-like interface. There is an entry in the
table for every entry in the dot3OamTable.
The counters in this table are defined as 32-bit entries to
match the counter size as defined in [802.3ah]. Given that
the OA protocol is a slow protocol, the counters increment at
a slow rate.
"
::= { dot3OamObjects 4 }
dot3OamStatsEntry OBJECT-TYPE
SYNTAX Dot3OamStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table containing statistics information on
the Ethernet OAM function for a single Ethernet-like
interface. Entries are automatically created for every entry
in the dot3OamTable. Counters are maintained across
transitions in dot3OamOperStatus.
"
INDEX { ifIndex }
::= { dot3OamStatsTable 1 }
Dot3OamStatsEntry ::=
SEQUENCE {
dot3OamInformationTx Counter32,
dot3OamInformationRx Counter32,
dot3OamUniqueEventNotificationTx Counter32,
dot3OamUniqueEventNotificationRx Counter32,
dot3OamDuplicateEventNotificationTx Counter32,
dot3OamDuplicateEventNotificationRx Counter32,
dot3OamLoopbackControlTx Counter32,
dot3OamLoopbackControlRx Counter32,
dot3OamVariableRequestTx Counter32,
dot3OamVariableRequestRx Counter32,
dot3OamVariableResponseTx Counter32,
Squire Standards Track [Page 23]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
dot3OamVariableResponseRx Counter32,
dot3OamOrgSpecificTx Counter32,
dot3OamOrgSpecificRx Counter32,
dot3OamUnsupportedCodesTx Counter32,
dot3OamUnsupportedCodesRx Counter32,
dot3OamFramesLostDueToOam Counter32
}
dot3OamInformationTx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of Information OAMPDUs transmitted on
this interface.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime. "
REFERENCE "[802.3ah], 30.3.6.1.20."
::= { dot3OamStatsEntry 1 }
dot3OamInformationRx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of Information OAMPDUs received on this
interface.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.21."
::= { dot3OamStatsEntry 2 }
dot3OamUniqueEventNotificationTx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of unique Event OAMPDUs transmitted on
this interface. Event Notifications may be sent in duplicate
to increase the probability of successfully being received,
Squire Standards Track [Page 24]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
given the possibility that a frame may be lost in transit.
Duplicate Event Notification transmissions are counted by
dot3OamDuplicateEventNotificationTx.
A unique Event Notification OAMPDU is indicated as an Event
Notification OAMPDU with a Sequence Number field that is
distinct from the previously transmitted Event Notification
OAMPDU Sequence Number.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.22."
::= { dot3OamStatsEntry 3 }
dot3OamUniqueEventNotificationRx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of unique Event OAMPDUs received on
this interface. Event Notification OAMPDUs may be sent in
duplicate to increase the probability of successfully being
received, given the possibility that a frame may be lost in
transit. Duplicate Event Notification receptions are counted
by dot3OamDuplicateEventNotificationRx.
A unique Event Notification OAMPDU is indicated as an Event
Notification OAMPDU with a Sequence Number field that is
distinct from the previously received Event Notification
OAMPDU Sequence Number.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.24."
::= { dot3OamStatsEntry 4 }
dot3OamDuplicateEventNotificationTx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of duplicate Event OAMPDUs transmitted
Squire Standards Track [Page 25]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
on this interface. Event Notification OAMPDUs may be sent in
duplicate to increase the probability of successfully being
received, given the possibility that a frame may be lost in
transit.
A duplicate Event Notification OAMPDU is indicated as an Event
Notification OAMPDU with a Sequence Number field that is
identical to the previously transmitted Event Notification
OAMPDU Sequence Number.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.23."
::= { dot3OamStatsEntry 5 }
dot3OamDuplicateEventNotificationRx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of duplicate Event OAMPDUs received on
this interface. Event Notification OAMPDUs may be sent in
duplicate to increase the probability of successfully being
received, given the possibility that a frame may be lost in
transit.
A duplicate Event Notification OAMPDU is indicated as an Event
Notification OAMPDU with a Sequence Number field that is
identical to the previously received Event Notification OAMPDU
Sequence Number.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.25."
::= { dot3OamStatsEntry 6 }
dot3OamLoopbackControlTx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of Loopback Control OAMPDUs transmitted
Squire Standards Track [Page 26]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
on this interface.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.26."
::= { dot3OamStatsEntry 7 }
dot3OamLoopbackControlRx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of Loopback Control OAMPDUs received
on this interface.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.27."
::= { dot3OamStatsEntry 8 }
dot3OamVariableRequestTx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of Variable Request OAMPDUs transmitted
on this interface.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.28."
::= { dot3OamStatsEntry 9 }
dot3OamVariableRequestRx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of Variable Request OAMPDUs received on
Squire Standards Track [Page 27]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
this interface.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.29."
::= { dot3OamStatsEntry 10 }
dot3OamVariableResponseTx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of Variable Response OAMPDUs
transmitted on this interface.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.30."
::= { dot3OamStatsEntry 11 }
dot3OamVariableResponseRx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of Variable Response OAMPDUs received
on this interface.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.31."
::= { dot3OamStatsEntry 12 }
dot3OamOrgSpecificTx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of Organization Specific OAMPDUs
Squire Standards Track [Page 28]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
transmitted on this interface.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.32."
::= { dot3OamStatsEntry 13 }
dot3OamOrgSpecificRx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of Organization Specific OAMPDUs
received on this interface.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.33."
::= { dot3OamStatsEntry 14 }
dot3OamUnsupportedCodesTx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of OAMPDUs transmitted on this
interface with an unsupported op-code.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.18."
::= { dot3OamStatsEntry 15 }
dot3OamUnsupportedCodesRx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of OAMPDUs received on this interface
Squire Standards Track [Page 29]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
with an unsupported op-code.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.19."
::= { dot3OamStatsEntry 16 }
dot3OamFramesLostDueToOam OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of frames that were dropped by the OA
multiplexer. Since the OAM multiplexer has multiple inputs
and a single output, there may be cases where frames are
dropped due to transmit resource contention. This counter is
incremented whenever a frame is dropped by the OAM layer.
Note that any Ethernet frame, not just OAMPDUs, may be dropped
by the OAM layer. This can occur when an OAMPDU takes
precedence over a 'normal' frame resulting in the 'normal'
frame being dropped.
When this counter is incremented, no other counters in this
MIB are incremented.
Discontinuities of this counter can occur at re-initialization
of the management system, and at other times as indicated by
the value of the ifCounterDiscontinuityTime.
"
REFERENCE "[802.3ah], 30.3.6.1.46."
::= { dot3OamStatsEntry 17 }
-
*
–
– Ethernet OAM Event Configuration group
–
dot3OamEventConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OamEventConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Ethernet OAM includes the ability to generate and receive
Event Notification OAMPDUs to indicate various link problems.
This table contains the mechanisms to enable Event
Squire Standards Track [Page 30]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
Notifications and configure the thresholds to generate the
standard Ethernet OAM events. There is one entry in the table
for every entry in dot3OamTable that supports OAM events
(where dot3OamFunctionsSupported includes the eventSupport
bit set). The values in the table are maintained across
changes to dot3OamOperStatus.
The standard threshold crossing events are:
- Errored Symbol Period Event. Generated when the number of
symbol errors exceeds a threshold within a given window
defined by a number of symbols (for example, 1,000 symbols
out of 1,000,000 had errors).
- Errored Frame Period Event. Generated when the number of
frame errors exceeds a threshold within a given window
defined by a number of frames (for example, 10 frames out
of 1000 had errors).
- Errored Frame Event. Generated when the number of frame
errors exceeds a threshold within a given window defined
by a period of time (for example, 10 frames in 1 second
had errors).
- Errored Frame Seconds Summary Event. Generated when the
number of errored frame seconds exceeds a threshold within
a given time period (for example, 10 errored frame seconds
within the last 100 seconds). An errored frame second is
defined as a 1 second interval which had >0 frame errors.
There are other events (dying gasp, critical events) that are
not threshold crossing events but which can be
enabled/disabled via this table.
"
::= { dot3OamObjects 5 }
dot3OamEventConfigEntry OBJECT-TYPE
SYNTAX Dot3OamEventConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries are automatically created and deleted from this
table, and exist whenever the OAM entity supports Ethernet OA
events (as indicated by the eventSupport bit in
dot3OamFunctionsSuppported). Values in the table are
maintained across changes to the value of dot3OamOperStatus.
Event configuration controls when the local management entity
sends Event Notification OAMPDUs to its OAM peer, and when
certain event flags are set or cleared in OAMPDUs.
"
INDEX { ifIndex }
::= { dot3OamEventConfigTable 1 }
Squire Standards Track [Page 31]
RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007
Dot3OamEventConfigEntry ::=
SEQUENCE {
dot3OamErrSymPeriodWindowHi Unsigned32,
dot3OamErrSymPeriodWindowLo Unsigned32,
dot3OamErrSymPeriodThresholdHi Unsigned32,
dot3OamErrSymPeriodThresholdLo Unsigned32,
dot3OamErrSymPeriodEvNotifEnable TruthValue,
dot3OamErrFramePeriodWindow Unsigned32,
dot3OamErrFramePeriodThreshold Unsigned32,
dot3OamErrFramePeriodEvNotifEnable TruthValue,
dot3OamErrFrameWindow Unsigned32,
dot3OamErrFrameThreshold Unsigned32,
dot3OamErrFrameEvNotifEnable TruthValue,
dot3OamErrFrameSecsSummaryWindow Integer32,
dot3OamErrFrameSecsSummaryThreshold Integer32,
dot3OamErrFrameSecsEvNotifEnable TruthValue,
dot3OamDyingGaspEnable TruthValue,
dot3OamCriticalEventEnable TruthValue
}
dot3OamErrSymPeriodWindowHi OBJECT-TYPE
SYNTAX Unsigned32
UNITS "2^32 symbols"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The two objects dot3OamErrSymPeriodWindowHi and
dot3OamErrSymPeriodLo together form an unsigned 64-bit
integer representing the number of symbols over which this
threshold event is defined. This is defined as
dot3OamErrSymPeriodWindow = 1)