MEF 30.1 is a specification document developed by the Technical Committee of the MEF to provide an Implementation Agreement for Service OAM Fault Management.


"This document specifies an Implementation Agreement (IA) for Service Operations, Administration, and Maintenance (OAM) that builds upon the framework and requirements specified by MEF 17 [16]. In particular, this IA specifies Service OAM requirements for Maintenance Entity Groups (MEGs) and for Fault Management (FM). Service OAM in general and FM in particular are defined in IEEE 802.1Q [3] and ITU-T Y.1731 [7]. This IA details how to use these functions to achieve the MEF requirements of Service OAM in general and Service OAM FM in particular."






  1. user-2a9a6

    Hi user-674ed & Daniel Bar-Lev,

    As per MEF30.1:

    [CD13]< [D66] AIS injections SHOULD be enabled only on MEPs in point to point MEGs.

    [CR4]< [D66]AIS SHOULD NOT be configured to be injected into any client MEGs that are not point-to-point.

    But as per Y.1731:

     "For multipoint ETH connectivity, a MEP cannot determine the specific server (sub) layer entity that has encountered defect conditions upon receiving a frame with ETH-AIS information. More importantly, it cannot determine the associated subset of its peer MEPs for which it should suppress alarms since the received ETH-AIS information does not contain that information. Therefore, upon reception of a frame with ETH-AIS information, the MEP will suppress alarms for all peer MEPs whether there is still connectivity or not."

    Why is this change in requirement in MEF with respect to Y.1731? 

    How far is this requirement followed for equipment certification?

    1. Hi Sham,

      I believe these statements are mutually consistent. Y.1731 points out that AIS is a big hammer. If you use it in a MEG then all alarms are squelched. If you have a multipoint service with MEPs A, B, C and there is a failure in the A-B path, then A-C path might be operating fine. If you use AIS in this MEG then a subsequent failure in the A-C won't be alarmed. Y.1731 doesn't say "don't do this", it just says that if you do it the results might cause a lack of reporting.

      The MEF documents just take this a bit farther and say "you shouldn't do it". This is consistent.

      I don't believe (although I am not positive) that AIS is part of the CE2.0 certification test.


  2. user-2a9a6

    Larry Samberg,

    Yes, in that view it looks consistent.

    But if we consider final conclusive requirement for implementation:

    1. Y.1731 says AIS injection can be enabled on MEPs in multipoint-multipoint MEGs.
    2. MEF30.1 says AIS injection should not be enabled on MEPs in multipoint-multipoint MEGs.

    Don't you think this creates confusion?

    And also do you think, there is any specific usecase for which Y.1731 suggested such requirement(like AIS hammer)?


  3. I don't think this causes confusion. There is no reason why the MEF specifications can't provide restrictions that are tighter than the standard. This is done in many, many contexts.

    If the standard said that you should not use AIS on multipoint flows and the MEF specification indicated that you should, that would be inconsistent. But in this case the standard simply indicates that the result could be cause a problem and the MEF says "dont do it"... That seems completely acceptable to me.

  4. user-2a9a6

    HI Folks,

    Had query on AIS indication signal which discussed in linkedin group at following location,

    Could you please clarify this?

    MEF30.1 requirement says "If the client MEG has a MEP on the same interface as the injecting MEP, then AIS indication should be sent to Client MEG". 

    1. Does AIS indication also suppress any alarms on client MEP by raising AIS alarm on client MEP?


    2. Primary alarm will be reported on client MEP in case of LOC as client & injecting MEP are on same interface?

  5. From Steve Mood:

    AIS suppresses MEP alarms on the MEG level that the AIS is detected . The AIS frame is sent on a user defined MEG that can be different than the detected AIS problem. It is sent away from the detecting interface. For instance if the AIS error was detected on MEG level 0 and was configured to be sent on MEG level 6, the AIS frame would be sent away from the source of the AIS fault. It is not sent on the same interface that detects the problem. AIS is a fault propagation method.

  6. user-2a9a6

    Larry SambergSteve Mood

    Agreed this behavior when client & injecting MEG on different interface (AIS PDU is injected towards client MEG) but as per MEF30.1

    "If the client MEG has a MEP on the same interface as the injecting MEP, then injecting an AIS is a simple matter of passing an indication internally within the device from one MEP to the other. In this case, no AIS PDU is transmitted. This is referred to as an “AIS Indication”. Note that as the client MEG is defined to be a MEG that encompasses the injecting MEG, the two MEPs will by definition face the same direction, i.e., both Up MEPs or both Down MEPs."

    In this case do we raise AIS alarm (here its AIS Indication not AIS PDU) on client MEG in turn suppress other alarms on it?


    Thanks & Regards

    Sham Naragund