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.