MEF 35.1 is a specification document developed by the Technical Committee of the MEF to provide an Implementation Agreement for Service OAM Performance Monitoring.

Abstract:

 

"This document specifies an Implementation Agreement (IA) for Service Operations, Administration,and Maintenance (SOAM) that satisfies and extends the Performance Monitoring (PM) framework and requirements described in MEF 17. Existing PM Functions are defined by ITU-T G.8013/Y.1731 [1], and ITU-T G.8021 [3] as amended. This document details how to use these functions in order to achieve the requirements of MEF SOAM PM."

Download

Status

PUBLISHED

Source(s)
Contributor(s)

ALU

AT&T

Bell Canada

Ciena

Cisco

Comcast

Ericsson

EXFO

Huawei

InfoVista

PLDT

RAD

Siama Systems

9 Comments

  1. user-2a9a6

    Hi Daniel Bar-Lev
    Thank you for quick response.

    Went through the MEF35.1 document. But could not find any specific reason for NOT having such requirement ("considering only qualified synthetic frames green synthetic frames") for metrics measurement in PM-1 & PM-2 solution.

    Thanks & Regards
    Sham Naragund

    1. Hi user-2a9a6

       

      Have you discussed this with the MEF 35.1 (MEF 35.1 Project) editor David Ball ?

       

      Thanks,

      Daniel

  2. user-2a9a6

    Hi Daniel Bar-Lev,

    Havent discuss with David before. Thank you for the reference.

    Hi David Ball

    As per MEF17 requirements (R3a), (R4a), (R4b), (R5a) & (R5b) metric measurements should be done only on green frames.

    Also MEF35.1, Section 7.2 again stresses on same as:

    "Each Service Frame must: have an Ingress Bandwidth Profile compliance of green (if it is subject to an Ingress Bandwidth Profile)".

    But PM-1 & PM-2 solutions doesnt have any such requirement (only PM-3 solution has) to consider green synthetic frames?

    1. Even though PM-1 & PM-2 is based on synthetic frame, these can also be affected by profile as basic definition of synthetic frame is to mimic service frames.
    2. These yellow synthetic frames can get delayed in queue or may get dropped.

    Could you please help me with the reason of NOT having requirement of considering green frames in PM-1 & PM-2?

     -Sham

     

    1. PM-1 and PM-2 use synthetic frames; the operator can configure the synthetic frames so as to mimic green or yellow traffic, and hence can measure the performance of either.  There is no need to restrict it in the document, it is up to the operator to choose.  There is some guidance in section 8.2.

      PM-3 measures loss of data frames, using the ETH-LM tool from ITU-T G.8013; it is defined in ITU-T G.8013 to only measure green frames.  This is necessary to ensure interoperability, i.e. it is required that both ends count the same frames.

      David

  3. user-2a9a6

    Hi David Ball

    Thank you for your input, but have more queries:

    Could you please elaborate if we can have following field scenario,

    1. In EVC MEG or Test MEG where multiple operators are involved say 4 operators.(Op1, Op2 Op3 & Op4).
    2. Even though user configured drop ineligible DMM/SLM tagged frame, as packet traverse through multiple operators there is probability that it becomes yellow in intermediate operator(Say in Op2).
    3. In this case DMM/SLM packet could be delayed/dropped respectively.
    4. Similarly for DMR/SLR packets.

    Also as you said : "The operator can configure the synthetic frames so as to mimic green or yellow traffic" but PM-1 & PM-2 have following requirement

    [R60] If the DMM frames are tagged and the VLAN DEI is supported, then a SOAM
    Implementation of a Controller MEP MUST use a VLAN DEI of 0 (discard
    ineligible) for DMM frame transmission.

    [R73] If the SLM frames are tagged and the VLAN DEI is supported, then a SOAM
    implementation of a Controller MEP MUST use a VLAN DEI of 0 (discard
    ineligible) for SLM frame transmission.

    [CR29]< [O6] If the 1DM frames are tagged and the VLAN DEI is supported, then a
    SOAM PM Implementation on the Controller MEP MUST use a VLAN DEI
    of 0 (discard ineligible) for 1DM frame transmission.

     

    Thanks & Regards

    Sham N.


     

    1. Sham,

      We need to take care here not to confuse the value of the DEI and PCP bits with whether the frame is considered to be green or yellow.

      If the Color ID is based on DEI, and if the Subscriber sends the frame with DEI=0, then it will arrive at the SP marked as green.  If there is no ingress BWP, then the SP must treat the frame and green and the SLS will apply to it.  The DEI might get changed by any of the operators (MEF 10.3 doesn't have a DEI Preservation attribute, it will be added in MEF 10.4), but nothing can change the fact that the SP has accepted it as green and so the SLS applies.  If the frame later gets dropped, it will count towards any FLR objective in the SLS.

      However, if the Subscriber has agreed an ingress BWP with the SP, then even though the frame arrives at the SP marked as green, it could be declared yellow by the ingress BWP.  In that case the SLS would not apply.

      Essentially, how the frame is treated depends only on what color it is declared as by the ingress BWP, or if there is no ingress BWP, what color it was marked as by the Subscriber.  If it is green, then the SLS applies; if it is yellow, then the SLS does not apply.  Nothing that any operator does afterwards can change that.

      BTW, yes you are right about those requirements, DMM and SLM frames have to be sent with DEI=0.

      David

  4. user-2a9a6

    Hi David Ball,

    Sorry for the confusion between color ID & DEI. Thank you for clearing it. 

    One small confusion landed in with one statement, could you please confirm it.

    "However, if the Subscriber has agreed an ingress BWP with the SP, then even though the frame arrives at the SP marked as green, it could be declared yellow by the ingress BWP.  In that case the SLS would not apply"

    And also as per 8.2 section of MEF35.1:

    "Subscriber MEG, UTA SP MEG: the MEPs do not coincide with the ingress and
    egress of the CEN, and hence the coloring of Service Frames may be altered by an
    Ingress or Egress Bandwidth Profile. This may result in different frames being
    counted by each MEP, leading to inaccuracies in the measurement.

    1. In above scenario if injected synthetic frames, will they be unaltered?
    2. I believed synthetic frame also go through same CHANGE (of color & subsequent behavior of delay/drop) like service frame, hence expecting SLS should not be applied?

    Please correct me If I dont allign with your thoughts.

    -Sham

    1. Hi Sham,

      1. In the case of the Subscriber MEG or UTA SP MEG, even synthetic frames that are injected could be declared a different color to how they were originally marked, or could have their PCP or DEI fields modified.
      2. If the synthetic frame was injected from within the CEN (e.g. by an Up MEP at the ingress UNI) then it is not a service frame therefore the SLS does not apply to it.  If the synthetic frame was injected outside the CEN (e.g. by a Subscriber MEP) and hence received over the ingress UNI, then it is a service frame and the same rules apply as for data service frames, i.e. the SLS only applies if it is declared green (and if the other conditions for being a Qualifed Service Frame are met).

      David

  5. user-2a9a6

    David Ball Thank you for detailed explanation.

    Summarizing our discussion:

    1. For Subscriber MEG or UTA SP MEG even SLM/DMM frames would be treated as service frame & for metric measurements only green SLM/DMM/SLR/DMR frames will be considered.

    2. All other MEGs as per definition in PM-1 or PM-2,color ID is not differentiated for SLM/SLR/DMM/DLR in turn metric measurements.