RAISECOM-DOT1AG-MIB Table View

There is one CFM Stack table per bridge. It permits
the retrieval of information about the Maintenance Points
configured on any given interface.

For each bridge component, the Default MD Level Managed Object
controls MHF creation for VIDs that are not attached to a
specific Maintenance Association Managed Object, and Sender ID
TLV transmission by those MHFs.
          
For each Bridge Port, and for each VLAN ID whose data can
pass through that Bridge Port, an entry in this table is
used by the algorithm in subclause 22.2.3 only if there is no
entry in the Maintenance Association table defining an MA
for the same VLAN ID and MD Level as this table's entry, and
on which MA an Up MEP is defined.  If there exists such an
MA, that MA's objects are used by the algorithm in
subclause 22.2.3 in place of this table entry's objects.  The
agent maintains the value of rcDot1agCfmDefaultMdStatus to
indicate whether this entry is overridden by an MA.
          
When first initialized, the agent creates this table
automatically with entries for all VLAN IDs,
with the default values specified for each object.
          
After this initialization, the writable objects in this
table need to be persistent upon reboot or restart of a
device.

This table defines the association of VIDs into VLANs.  There
is an entry in this table, for each component of the bridge,
for each VID that is:
    a) a VID belonging to a VLAN associated with more than
       one VID; and
    b) not the Primary VLAN of that VID.
The entry in this table contains the Primary VID of the VLAN.
          
By default, this table is empty, meaning that every VID is
the Primary VID of a single-VID VLAN.
          
VLANs that are associated with only one VID SHOULD NOT have
an entry in this table.
          
The writable objects in this table need to be persistent
upon reboot or restart of a device.

The CFM Configuration Error List table provides a list of
Interfaces and VIDs that are incorrectly configured.

The Maintenance Domain table. Each row in the table
represents a different Maintenance Domain.
          
A Maintenance Domain is described in 802.1ag (3.21) 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.
          
This is the part of the complete MA table that is constant
across all Bridges in a Maintenance Domain, and across all
components of a single Bridge.  That part of the MA table that
can vary from Bridge component to Bridge component is contained
in the rcDot1agCfmMaCompTable.
          
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.16 and 18.2).
          
This table uses two indices, first index is the index of the
Maintenance Domain table.  The second index is the same as the
index of the rcDot1agCfmMaCompEntry for the same MA.
          
The writable objects in this table need to be persistent
upon reboot or restart of a device.

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.
          
This is the part of the complete MA table that is variable
across the Bridges in a Maintenance Domain, or across the
components of a single Bridge.  That part of the MA table that
is constant across the Bridges and their components in a
Maintenance Domain is contained in the rcDot1agCfmMaNetTable.
          
This table uses three indices, first index is the
rcDot1agCfmPbbComponentIdentifier that identifies the component
within the Bridge for which the information in the
rcDot1agCfmMaCompEntry applies.  The second is the index of the
Maintenance Domain table.  The third index is the same as the
index of the rcDot1agCfmMaNetEntry for the same MA.
          
The writable objects in this table need to be persistent
upon reboot or restart of a device.

List of MEPIDs that belong to this 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.
          
For all bridges in which the same MAID {rcDot1agCfmMdFormat,
rcDot1agCfmMdName, rcDot1agCfmMaNetFormat, and rcDot1agCfmMaNetName}
is configured, the same set of rcDot1agCfmMaMepListIdentifiers
must be configured in the bridges' rcDot1agCfmMaMepListTables.
This allows each MEP to determine whether or not it is
receiving CCMs from all of the other MEPs in the MA.
          
For example, if one were creating a new MA whose MAID were
{charString, 'Dom1', charString, 'MA1'}, that had 2 MEPs, whose
MEPIDs were 1 and 3, one could, in Bridge A:
 1. Get a new MD index d from rcDot1agCfmMdTableNextIndex.
 2. Create the Maintenance Domain {charString, 'Dom1'}.
 3. Get a new MA index a from rcDot1agCfmMdMaNextIndex [d].
 4. Create the Maintenance Association {charString, 'MA1'}.
 5. Create a new rcDot1agCfmMaMepListEntry for each of the MEPs
    in the MA: [d, a, 1] and [d, a, 3].
 6. Create one of the new MEPs, say [d, a, 1].
Then, in Bridge B:
 7. Do all of these steps 1-6, except for using the other MEPID
    for the new MEP in Step 6, in this example, MEPID 3.
Note that, when creating the MA, MEP List Table, and MEP
entries in the second bridge, the indices 'd' and 'a'
identifying the MAID {charString, 'Dom1', charString, 'MA1'}
may have different values than those in the first Bridge.

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.17).
          
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 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 rcDot1agCfmMepTransmitLbmStatus value to be
   true.  To do this do this sequence:
   a. an SNMP GET for both SnmpSetSerialNo and
      rcDot1agCfmMepTransmitLbmStatus objects (in same SNMP
      PDU).
   b. Check if value for rcDot1agCfmMepTransmitLbmStatus is true.
      - 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 rcDot1agCfmMepTransmitLbmStatus value from true to
   false 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 rcDot1agCfmMepTransmitLbmStatus 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,...), except do not set
   rcDot1agCfmMepTransmitLbmMessages.
4) Record the current values of rcDot1agCfmMepLbrIn,
   rcDot1agCfmMepLbrInOutOfOrder, and rcDot1agCfmMepLbrBadMsdu.
6) Set rcDot1agCfmMepTransmitLbmMessages to a non-zero value to
   initiate transmission of Loopback messages.
7) Check the value of rcDot1agCfmMepTransmitLbmResultOK to
   find out if the operation was successfully initiated or
   not.
8) Monitor the value of rcDot1agCfmMepTransmitLbmMessages.
   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 rcDot1agCfmMepLbrIn, rcDot1agCfmMepLbrInOutOfOrder,
   and rcDot1agCfmMepLbrBadMsdu to their old values from step
   4, above, to get the results of the test.
10) Change the rcDot1agCfmMepTransmitLbmStatus value back to
   true 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, except
transmission is initiated by writing a value to the
rcDot1agCfmMepTransmitLtmFlags object.  Upon
successfully initiating the transmission, the variables
rcDot1agCfmMepTransmitLtmSeqNumber and
rcDot1agCfmMepTransmitLtmEgressIdentifier return the information
required to recover the results of the LTM from the
rcDot1agCfmLtrTable.

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.