| Description | At initialization and failure conditions, two OAM entities on
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 OAM
sublayer.
This value is always disabled(1) if OAM is disabled on this
interface via the cdot3OamAdminState.
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 (cdot3OamMode) and reflects the state in which the
OAM entity is waiting to see if the peer device is OAM
capable. The activeSendLocal(4) value is used by active mode
devices (cdot3OamMode) 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 OAM
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
the peering or has just not yet decided. This is indicated
via the remote flags field in the OAM PDU (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 (cdot3OamAdminState is enabled(1)) but the interface is
in half-duplex operation. |
| Syntaxe | Enumeration (1-disabled, 2-linkFault, 3-passiveWait, 4-activeSendLocal, 5-sendLocalAndRemote, 6-sendLocalAndRemoteOk, 7-oamPeeringLocallyRejected, 8-oamPeeringRemotelyRejected, 9-operational, 10-nonOperHalfDuplex) |