OID reference

fsMIEcfmExtMepTable

1.3.6.1.4.1.29601.2.13.1.2.3

Description

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, a…

Full description and source information

Identification

Identifier and names

Parent
1.3.6.1.4.1.29601.2.13.1.2 (fsMIEcfmExtContext)
Node code
3
Node name
fsMIEcfmExtMepTable
Category
SNMP management object
Numeric OID
1.3.6.1.4.1.29601.2.13.1.2.3
URN notation
urn:oid:1.3.6.1.4.1.29601.2.13.1.2.3
ASN.1, OID-IRI and named path variants
ASN.1 notation

{1 3 6 1 4 1 29601 2 13 1 2 3}

  • {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprises(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) identified-organization(3) dod(6) internet(1) private(4) ldap-enterprise(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) identified-organization(3) dod(6) internet(1) private(4) vendor-objects(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) org(3) dod(6) internet(1) private(4) ldap-enterprise(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) org(3) dod(6) internet(1) private(4) vendor-objects(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) enterprises(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) ldap-enterprise(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) vendor-objects(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) iso-organization(3) dod(6) internet(1) private(4) enterprise(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) iso-organization(3) dod(6) internet(1) private(4) enterprises(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) iso-organization(3) dod(6) internet(1) private(4) ldap-enterprise(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
  • {iso(1) iso-organization(3) dod(6) internet(1) private(4) vendor-objects(1) 29601 2 fsMIEcfmExtMIB(13) fsMIEcfmExtMIBObjects(1) fsMIEcfmExtContext(2) fsMIEcfmExtMepTable(3)}
OID-IRI notation
  • /1/3/6/1/4/1/29601/2/13/1/2/3
  • /ISO/Identified-Organization/6/1/4/1/29601/2/13/1/2/3
  • /ISO/3/6/1/4/1/29601/2/13/1/2/3
Named path variants
  • /iso/identified-organization/dod/internet/private/enterprise/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/identified-organization/dod/internet/private/enterprises/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/identified-organization/dod/internet/private/ldap-enterprise/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/identified-organization/dod/internet/private/vendor-objects/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/org/dod/internet/private/enterprise/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/org/dod/internet/private/enterprises/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/org/dod/internet/private/ldap-enterprise/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/org/dod/internet/private/vendor-objects/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/iso-identified-organization/dod/internet/private/enterprise/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/iso-identified-organization/dod/internet/private/enterprises/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/iso-identified-organization/dod/internet/private/ldap-enterprise/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/iso-identified-organization/dod/internet/private/vendor-objects/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/iso-organization/dod/internet/private/enterprise/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/iso-organization/dod/internet/private/enterprises/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/iso-organization/dod/internet/private/ldap-enterprise/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable
  • /iso/iso-organization/dod/internet/private/vendor-objects/29601/2/fsMIEcfmExtMIB/fsMIEcfmExtMIBObjects/fsMIEcfmExtContext/fsMIEcfmExtMepTable

SNMP properties

Value type
SEQUENCE OF FsMIEcfmExtMepEntry
Maximum access defined by MIB
not-accessible
Status in MIB
current

Properties come from available MIB definitions. Actual device support and access can differ. See source records below for original files and qualifications.

The displayed source records contain one distinct definition. Compare its source records.

fsMIEcfmExtMepTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF FsMIEcfmExtMepEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
       "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 fsMIEcfmExtMepTransmitLbmStatus value to be
           'ready'.  To do this do this sequence:
           a. an SNMP GET for both SnmpSetSerialNo and
              fsMIEcfmExtMepTransmitLbmStatus objects (in same SNMP
              PDU).
           b. Check if value for fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepLbrIn,
           fsMIEcfmExtMepLbrInOutOfOrder, and fsMIEcfmExtMepLbrBadMsdu.
        6) Change fsMIEcfmExtMepTransmitLbmStatus value from 'notReady'
           to 'transmit' to initiate transmission of Loopback
           messages.
        7) Check the value of fsMIEcfmExtMepTransmitLbmResultOK to
           find out if the operation was successfully initiated or
           not.
        8) Monitor the value of fsMIEcfmExtMepTransmitLbmMessages.
           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 fsMIEcfmExtMepLbrIn, fsMIEcfmExtMepLbrInOutOfOrder,
           and fsMIEcfmExtMepLbrBadMsdu to their old values from step
           4, above, to get the results of the test.
       10) Change the fsMIEcfmExtMepTransmitLbmStatus 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
        fsMIEcfmExtMepTransmitLtmSeqNumber and
        fsMIEcfmExtMepTransmitLtmEgressIdentifier return the information
        required to recover the results of the LTM from the
        fsMIEcfmLtrTable.
       "
    REFERENCE
       "802.1ag clauses 12.14.7 and 19.2"
    ::= { fsMIEcfmExtContext 3 }

Meaning

Descriptions

1 unique

Identical descriptions are grouped. Different wording and device-specific notes are retained.

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 fsMIEcfmExtMepTransmitLbmStatus value to be 'ready'. To do this do this sequence: a. an SNMP GET for both SnmpSetSerialNo and fsMIEcfmExtMepTransmitLbmStatus objects (in same SNMP PDU). b. Check if value for fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepLbrIn, fsMIEcfmExtMepLbrInOutOfOrder, and fsMIEcfmExtMepLbrBadMsdu. 6) Change fsMIEcfmExtMepTransmitLbmStatus value from 'notReady' to 'transmit' to initiate transmission of Loopback messages. 7) Check the value of fsMIEcfmExtMepTransmitLbmResultOK to find out if the operation was successfully initiated or not. 8) Monitor the value of fsMIEcfmExtMepTransmitLbmMessages. 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 fsMIEcfmExtMepLbrIn, fsMIEcfmExtMepLbrInOutOfOrder, and fsMIEcfmExtMepLbrBadMsdu to their old values from step 4, above, to get the results of the test. 10) Change the fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLtmSeqNumber and fsMIEcfmExtMepTransmitLtmEgressIdentifier return the information required to recover the results of the LTM from the fsMIEcfmLtrTable.

Sources for this description

Multiple manufacturers; see the original MIB MIB copies (LibreNMS/Observium Community)Belden, GarrettCom and Hirschmann IT official standalone MIBs

See 1 matching source record

Evidence

Source records

1 records

Matching descriptions are grouped; open a group to compare definitions and supporting files.

Records for description 1Multiple manufacturers; see the original MIB MIB copies (LibreNMS/Observium Community), Belden, GarrettCom and Hirschmann IT official standalone MIBs1 record · 2 sources

Description 1

fsMIEcfmExtMepTable · currentMultiple manufacturers; see the original MIB MIB copies (LibreNMS/Observium Community), Belden, GarrettCom and Hirschmann IT official standalone MIBs2 sources

Status in source: current.

Names: fsMIEcfmExtMepTable

Technical details
{
  "smi_kind": "OBJECT-TYPE",
  "definition": [
    "fsMIEcfmExtMepTable",
    "OBJECT-TYPE",
    "SYNTAX",
    "SEQUENCE",
    "OF",
    "FsMIEcfmExtMepEntry",
    "MAX-ACCESS",
    "not-accessible",
    "STATUS",
    "current",
    "DESCRIPTION",
    "\"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 fsMIEcfmExtMepTransmitLbmStatus value to be 'ready'. To do this do this sequence: a. an SNMP GET for both SnmpSetSerialNo and fsMIEcfmExtMepTransmitLbmStatus objects (in same SNMP PDU). b. Check if value for fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepLbrIn, fsMIEcfmExtMepLbrInOutOfOrder, and fsMIEcfmExtMepLbrBadMsdu. 6) Change fsMIEcfmExtMepTransmitLbmStatus value from 'notReady' to 'transmit' to initiate transmission of Loopback messages. 7) Check the value of fsMIEcfmExtMepTransmitLbmResultOK to find out if the operation was successfully initiated or not. 8) Monitor the value of fsMIEcfmExtMepTransmitLbmMessages. 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 fsMIEcfmExtMepLbrIn, fsMIEcfmExtMepLbrInOutOfOrder, and fsMIEcfmExtMepLbrBadMsdu to their old values from step 4, above, to get the results of the test. 10) Change the fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLtmSeqNumber and fsMIEcfmExtMepTransmitLtmEgressIdentifier return the information required to recover the results of the LTM from the fsMIEcfmLtrTable. \"",
    "REFERENCE",
    "\"802.1ag clauses 12.14.7 and 19.2\"",
    "::=",
    "{",
    "fsMIEcfmExtContext",
    "3",
    "}"
  ],
  "syntax_tree": [
    [
      "conceptualTable",
      [
        "row",
        "FsMIEcfmExtMepEntry"
      ]
    ],
    null,
    [
      "MaxAccessPart",
      "not-accessible"
    ],
    [
      "Status",
      "current"
    ],
    [
      "DESCRIPTION",
      "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 fsMIEcfmExtMepTransmitLbmStatus value to be 'ready'. To do this do this sequence: a. an SNMP GET for both SnmpSetSerialNo and fsMIEcfmExtMepTransmitLbmStatus objects (in same SNMP PDU). b. Check if value for fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepLbrIn, fsMIEcfmExtMepLbrInOutOfOrder, and fsMIEcfmExtMepLbrBadMsdu. 6) Change fsMIEcfmExtMepTransmitLbmStatus value from 'notReady' to 'transmit' to initiate transmission of Loopback messages. 7) Check the value of fsMIEcfmExtMepTransmitLbmResultOK to find out if the operation was successfully initiated or not. 8) Monitor the value of fsMIEcfmExtMepTransmitLbmMessages. 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 fsMIEcfmExtMepLbrIn, fsMIEcfmExtMepLbrInOutOfOrder, and fsMIEcfmExtMepLbrBadMsdu to their old values from step 4, above, to get the results of the test. 10) Change the fsMIEcfmExtMepTransmitLbmStatus 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 fsMIEcfmExtMepTransmitLtmSeqNumber and fsMIEcfmExtMepTransmitLtmEgressIdentifier return the information required to recover the results of the LTM from the fsMIEcfmLtrTable."
    ],
    [
      "REFERENCE",
      "802.1ag clauses 12.14.7 and 19.2"
    ],
    null,
    null,
    null
  ]
}

Registration

Registration authorities

First Registration Authority (inferred from ancestor 1.3.6.1.4.1.29601)

Arpna Gupta

Direct children (1)

OIDNameDirect childrenDescendantsDescription
1.3.6.1.4.1.29601.2.13.1.2.3.1 fsMIEcfmExtMepEntry4646

Siblings (2)

OIDNameDirect childrenDescendantsDescription
1.3.6.1.4.1.29601.2.13.1.2.1 fsMIEcfmExtDefaultMdTable17
1.3.6.1.4.1.29601.2.13.1.2.2 fsMIEcfmExtMaTable112