The Link Trace procedure identifies all MIPs and MEPs belonging to a ME. It can be thought of as a "layer 2 trace route". The procedure is similar to the loopback procedure.

A MEP initiates the Link Trace by sending an LTM message using a multicast MAC DA and the appropriate MEG level for the ME. It is recommended that LTM makes use of the highest CoS ID available, which will yield the lowest possible loss for a particular ETH service (EVC or OVC). Each MIP that belongs to this ME and the remote MEP:

  • replies by generating a Link Trace Response LTR unicast message
  • forwards the LTM onward towards the remote MEP (except for the MEP)

If there are no faults in the path, Link Trace allows the originator to map the entire route to the remote MEP. If there is a fault in the path, the originator will receive LTRs from all MIPs before the fault thereby facilitating fault isolation.

On the Subscriber MEG, LTM PDUs should be sent with same CE-VLAN ID that maps to the monitored EVC, that way it is guaranteed that the LTM passes the same path as the monitored EVC's service frames.




In this example, an LTM procedure is issued from MEP1. MIP1 and MIP2 reply, but MIP3 does not reply.


The failure is between MIP2 and MIP3, or at the NE implementing MIP3.


Since none of the MIPs nor the MEP beyond MIP2 receive the LTM, they will not (attempt to) send an LTR.


Related and Further Reading






Source(s) and Reference(s)







  1. Anonymous

    Hi all,

    I have two questions:

    1) is it possible to generate an LTM having Target MAC address of a MIP and not of a MEP?

    2) is it possible that between the two MEPs in the picture there are other MEPs that act like a MIP, that is forward LTM and reply with LTR?

    1. Hi Anonymous,


      With respect to #1 ... LTMs are not sent to a target address, the are always sent to a multicast address, so the question is not really meaningful.

                 From Y.1731:  "LTM frames are generated with a multicast Class 2 DA."


      With respect to #2 ... No. MEPs don't act like MIPs. If an LTM hits a MEP, the MEP will respond but the LTM is not forwarded any further.

  2. Anonymous

    Thanks for the response,

    with respect to #1, I mean that in the payload of LTM there is a field called Target MAC address that identify the Maintenance Point that I'm polling, isn't so? If so, I'm wondering if this MP should be necessary a MEP or it may also be a MIP.




    1. Ah... Interesting question. Never thought of this possibility. But, in fact, it is covered in the standard (Y.1731) see bolded text:


      The Ethernet link trace function (ETH-LT) is an on-demand OAM function that can be used for the following two purposes:

      • Adjacent relation retrieval – The ETH-LT function can be used to retrieve adjacency relationship between a MEP and a remote MEP or MIP. The result of running ETH-LT function is a sequence of MIPs from the source MEP until the target MIP or MEP. Each MIP and/or MEP is identified by its MAC address.

      • Fault localization – The ETH-LT function can be used for fault localization. When a fault (e.g., a link and/or a device failure) or a forwarding plane loop occurs, the sequence of MIPs and/or MEP will likely be different from the expected one. Difference in the sequences provides information about the fault location.


      So it appears that you can target a MIP in the LTM, as well as a MEP.


      Also, if you continue reading that section (7.3) in the standard you will note that my response to the second half of your question was incorrect (sorry about that). It does appear to allow a MEP (as well as a MIP) to forward an LTM if it "is aware of the TargetMAC address in the ETH-LT request information and associates it to a single egress port".  And actually this seems to make sense. A topology where a UNI exists on a system and the next UNI is beyond that system is perfectly reasonable.