The Extended MEP table stores all the managed objects for
setting the CFM standard of the MEP (Y1731, dot1ag, or hybrid), for
sending LMM/DMM, for enabling transmission of RDI and AIS, for
enabling EFD functionality, and for controlling Multicast Loopbacks.
It is an extension of the standard MEP table.
(AUGMENT - it uses the same indexes as the standard MEP table
dot1agCfmMepTable)
*LMM Managed objects
LMM Managed objects in the extended MEP table enable the management
entity to initiate transmission of Frame Loss messages. It will signal
the MEP that it should start to transmit Frame Loss messages (LMM)
and retrieve the information received from the Frame Loss
Responses (LMR).
Steps to use entries in this table:
1) Wait for oacEthOamMepLossStatus value to be
false. To do this do this sequence:
a. an SNMP GET for both SnmpSetSerialNo and
oacEthOamMepLossStatus objects (in same SNMP
PDU).
b. Check if value for oacEthOamMepLossStatus is false.
- if not, wait x seconds, go to step a above.
- if yes, save the value of SnmpSetSerialNo and go
to step 2) below
2) Change oacEthOamMepLossStatus value from false to
true to ensure no other management entity will use
the service. In order to not disturb a possible other NMS
do this by sending an SNMP SET for both SnmpSetSerialNo
and oacEthOamMepLossStatus objects (in same SNMP
PDU, and make sure SNmpSetSerialNo is the first varBind).
For the SnmpSetSerialNo varBind, use the value that you
obtained in step 1)a. This ensures that two cooperating
NMSes will not step on each others toes.
3) Setup the different data to be sent (destination, priority,
interval,...), except do not set oacEthOamMepLossMessagesStart.
4) Set oacEthOamMepLossMessagesStart to true to initiate
transmission of Frame Loss messages.
5) Check the value of oacEthOamMepLossResultOK to
find out if the operation was successfully initiated or
not.
6) The results of the running test can be retrieved from
oacEthOamMepLossNbrOfTxFrames, oacEthOamMepLossNbrOfRxFrames,
oacEthOamMepLossReplyLoss, oacEthOamMepLossNearEndDrops and
oacEthOamMepLossFarEndDrops.
7) If you so desire, you can periodically stop and/or restart
transmission of LMM messages by modifying the
oacEthOamMepLossMessagesStart accordingly.
8) Change the oacEthOamMepLossStatus value back to
false to allow other management entities to use the
table. Setting oacEthOamMepLossStatus to false obviously implies
that LMMs will no longer be transmitted, and that as such the value
of oacEthOamMepLossMessagesStart will be ignored.
*DMM Managed objects
The DMM Managed objects in the extended MEP table are used in a manner
similar to that described for LMM transmission, above. Upon
successfully initiating the transmission, the objects
oacEthOamMepDelayNbrOfTxFrames, oacEthOamMepDelayNbrOfRxFrames,
oacEthOamMepDelayLoss, oacEthOamMepDelayMin, oacEthOamMepDelayMax,
oacEthOamMepDelayAvrg, oacEthOamMepDelayJitterNegMax,
oacEthOamMepDelayJitterAvrgMax, oacEthOamMepDelayJitterPosMax
contain the result of the test.
*AIS managed objects
The AIS managed objects in the extended MEP table are used in a manner
similar to that described for LMM transmission. In short, first all
managed objects except oacEthOamMepAisTxEnable must be set, then
oacEthOamMepAisTxEnable must be set to true to enable transmission of
AIS. Set it to false to disable transmission again.
*Multicast Loopbacks
The Multicast Loopback managed objects are used as follows. If wanted,
the SNMP manager first sets the oacEthOamMepMcastLbmDataTlv payload,
or makes sure that the string is empty if no DataTLV is wanted.
Next, the SNMP manager must wait for the oacEthOamMepMcastLbmStatus
flag to be false.
Then, the oacEthOamMepMcastLbmStatus flag must be set to true to
initiate transmission of the Multicast LBM. Then the SNMP manager must
wait until the MEP Multicast Loopback Initiator State Machine has set
this flag back to false, which indicates that the time to wait for
loopback replies has expired. Finally, the oacEthOamLbrNotRespTable and
oacEthOamExtLbrTable tables can be consulted to evaluate the results.
*EFD Managed Objects
CFM could be considered as a line protocol for controlling Ethernet
interfaces. In case of Loss of Continuity or AIS or RDI reception,
the interface can be disabled. This feature is called Ethernet Fault
Detection and Propagation, or EFD. It is only available for inward
facing MEPs. When the interface, to which the inward facing MEP
belongs, is disabled, the MEP stays up and CFM frames are still
flowing. When the defect disappears, EFD will bring the MEP's interface
up again.
EFD can be enabled with the oacEthOamMepEfdEnable managed object. If
more than one inward facing MEP is configured for a specific interface,
then EFD can only be enabled on one of these MEPs.
Once enabled, the EFD state of the interface can be retrieved from the
oacEthOamMepEfdState managed object. In case EFD is triggered, object
dot1agCfmMepDefects from the IEEE8021-CFM-MIB MIB can be used to
further investigate the cause(s) of the EFD trigger.
|