ZXR10-CFM-MIB Table View

The Maintenance Domain table. Each row in the table
represents a different Maintenance Domain.
A Maintenance Domain is described in 802.1ag (3.22) as the
network or the part of the network for which faults in
connectivity are to be managed. The boundary of a Maintenance
Domain is defined by a set of DSAPs, each of which can become
a point of connectivity to a service instance.

The Maintenance Association table. Each row in the table
represents an MA. An MA is a set of MEPs, each configured
with a single service instance.
Creation of a Service Instance establishes a connectionless
association among the selected DSAPs. Configuring a
Maintenance association End Point (MEP) at each of the
DSAPs creates a Maintenance Association (MA) to monitor
that connectionless connectivity. The MA is identified by a
Short MA Name that is unique within the Maintenance Domain
and chosen to facilitate easy identification of the Service
Instance. Together, the Maintenance Domain Name and the
Short MA Name form the Maintenance Association Identifier
(MAID) that is carried in CFM Messages to identify
incorrect connectivity among Service Instances. A small
integer, the Maintenance association End Point Identifier
(MEPID), identifies each MEP among those configured on a
single MA (802.1ag clauses 3.17 and 18.2).
This table uses two indices, first index is the index of the
Maintenance Domain table.
The writable objects in this table need to be persistent
upon reboot or restart of a device.

List of Vlan.

List of MEPIDs (in any bridge) that belong to the same MA.
Clause 12.14.6.1.3 specifies that a list of MEPIDs in all
bridges in that MA, but since SNMP SMI does not allow to
state in a MIB that an object in a table is an array, the
information has to be stored in another table with two
indices, being the first index, the index of the table that
contains the list or array.

The Maintenance Association End Point (MEP) table.
Each row in the table represents a different MEP. A MEP is
an actively managed CFM entity, associated with a specific
DSAP of a Service Instance, which can generate and receive
CFM PDUs and track any responses. It is an end point of a
single Maintenance Association, and is an endpoint of a
separate Maintenance Entity for each of the other MEPs in
the same Maintenance Association (802.1ag clause 3.18).
This table uses three indices. The first two indices are the
indices of the Maintenance Domain and MA tables, the reason
being that a MEP is always related to an MA and Maintenance
Domain.
The Transmit Loopback table. Entries in this table are
created/removed at the same time than entries in the MEP
table are created/removed.
The MEP table also stores all the managed objects for sending
LBM and LTM.
*LBM Managed objects
LBM Managed objects in the MEP table
enables the management entity to initiate
transmission of Loopback messages. It will signal the MEP
that it should transmit some number of Loopback messages
and detect the detection (or lack thereof) of the
corresponding Loopback messages.
Steps to use entries in this table:
1) Wait for dot1agCfmMepTransmitLbmStatus value to be
'ready'. To do this do this sequence:
a. an SNMP GET for both SnmpSetSerialNo and
dot1agCfmMepTransmitLbmStatus objects (in same SNMP
PDU).
b. Check if value for dot1agCfmMepTransmitLbmStatus is
'ready'
- 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 dot1agCfmMepTransmitLbmStatus value from 'ready' to
'notReady' 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 dot1agCfmMepTransmitLbmStatus 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 (number of messages,
optional TLVs,...).
4) Record the current values of dot1agCfmMepLbrIn,
dot1agCfmMepLbrInOutOfOrder, and dot1agCfmMepLbrBadMsdu.
6) Change dot1agCfmMepTransmitLbmStatus value from 'notReady'
to 'transmit' to initiate transmission of Loopback
messages.
7) Check the value of dot1agCfmMepTransmitLbmResultOK to
find out if the operation was successfully initiated or
not.
8) Monitor the value of dot1agCfmMepTransmitLbmMessages.
When it reaches 0, the last LBM has been transmitted.
Wait an additional 5 seconds to ensure that all LBRs have
been returned.
9) Compare dot1agCfmMepLbrIn, dot1agCfmMepLbrInOutOfOrder,
and dot1agCfmMepLbrBadMsdu to their old values from step
4, above, to get the results of the test.
10) Change the dot1agCfmMepTransmitLbmStatus value back to
'ready' to allow other management entities to use the
table.
*LTM Managed objects
The LTM Managed objects in the MEP table are used in a manner
similar to that described for LBM transmission, above. Upon
successfully initiating the transmission, the variables
dot1agCfmMepTransmitLtmSeqNumber and
dot1agCfmMepTransmitLtmEgressIdentifier return the information
required to recover the results of the LTM from the
dot1agCfmLtrTable.

This table extends the MEP table and contains a list of
Linktrace replies received by a specific MEP in response to
a linktrace message.
SNMP SMI does not allow to state in a MIB that an object in
a table is an array. The solution is to take the index (or
indices) of the first table and add one or more indices.

The MEP Database. A database, maintained by every MEP, that
maintains received information about other MEPs in the
Maintenance Domain.
The SMI does not allow to state in a MIB that an object in
a table is an array. The solution is to take the index (or
indices) of the first table and add one or more indices.

MIP Table