Skip to content

Methodology · Carrier Ethernet OAM

ITU-T Y.1731: do your OAM counters tell the truth about faults, delay and loss

Y.1731 (G.8013) gives a carrier Ethernet service its own nervous system: continuity checks every 3.3 ms to 10 minutes, loopback and linktrace to find a break, alarm indication across maintenance levels, and the delay and loss frames behind the SLA dashboard. We put a device or a whole path on the bench, emulate the peer MEPs, cut links, add load and impairment, and compare every OAM figure with what the generator measured on the same frames.

  • Fault management: CCM with RDI, loopback, linktrace and AIS across MEG levels 0 to 7, with detection time measured on the wire
  • Performance monitoring: two-way DMM/DMR, one-way 1DM with a common clock at both ends, LMM/LMR and synthetic SLM/SLR, each against a reference
  • Scale and stress: the agreed MEP count at 3.3 ms and 10 ms, 80 to 95 % line load, protection switching with CCM running
Get a Y.1731 test plan Jump to the six tests
CONTINUITY CHECK · FAULT DETECTION CCM EVERY 3.3 ms CCM RECEIVED CCM MISSED LOC DECLARED RDI FROM PEER 0 ms 10 20 30 40 LINK FAULT · 18 ms 3.5 INTERVALS = 11.7 ms LOC RDI PROTECTION SWITCH Three and a half missed CCMs: the fault is declared, not guessed

CCM at 3.3 ms: loss of continuity 3.5 intervals after the last frame received, RDI from the peer, then the protection switch

Where it fits

Activation proves a circuit once. OAM has to watch it every second after

Y.1564 turns a service up. Y.1731 is what the operator and the customer rely on afterwards, so its numbers must match reality before the SLA is signed

New NID or demarcation device

A device class that will sit at hundreds of customer sites. One unit on the bench shows whether its MEPs detect in time, answer loopback and linktrace at every level and report delay and loss the customer will accept

Two vendors on one MEG

Operator switch on one end, customer router on the other, or an aggregation node from a third supplier in between. Interop is checked level by level, with CCM, RDI and AIS crossing the boundary in both directions

An SLA dashboard people must believe

Delay and loss on the portal come from DMM and LMM frames. If those frames travel in a different queue from the service, the portal stays green while the customer complains. The bench finds that before the contract does

Test bed

Emulated MEPs on one side, the device or path in the middle, a peer on the other

The generator plays the maintenance end points the device will meet in the field, carries service traffic on the same port, and keeps its own timestamps and counters as the reference for every OAM result

GENERATOR · ANALYSER · SITE A EMULATED MEPs + SERVICE TRAFFIC ONE MEP PER SERVICE AND LEVEL CCM at 3.3 ms, 10 ms or 100 ms, RDI on DMM and LMM at the service priority Background load 0 to 95 % of line rate Reference delay and loss per frame OAM AND PAYLOAD ON ONE PORT UNI A CCM · DMM · LMM DEVICE OR NETWORK UNDER TEST NID · DEMARCATION · AGGREGATION · PE LEVEL 2 · OPERATORMEP · MIP LEVEL 4 · PROVIDERMEP · MIP LEVEL 6 · CUSTOMERPASSES THROUGH EACH LEVEL ANSWERS ITS OWN, FORWARDS THE HIGHER MEG LEVELS 0–7 CCM 3.3 ms–10 min G.8031 · G.8032 1G · 10G · 100G PORTS PTP OR GPS FOR 1DM UNI B CCM · DMR · LMR FAR END · SITE B PEER MEP: SECOND UNIT OR THE DEVICE WHAT THE FAR END GIVES CCM back, with RDI when it sees a fault DMR and LMR with its own timestamps WAN emulator: known delay and loss With PTP or GPS: one-way 1DM DETECTION · DELAY · LOSS · AVAILABILITY BED FIRST, DEVICE SECOND generator MEP to generator MEP through the same optics: zero CCM loss at 3.3 ms, DM within 1 µs of the reference, LM equal to the counted loss

Generator and analyser

One MEP per service and level, CCM at the agreed interval with RDI, DMM and LMM at the priority of the service, and the service traffic itself with a sequence number and a timestamp in every frame, from idle to 95 % of line rate

Device or network under test

A NID, demarcation device, aggregation switch or MPLS PE carrying the EVC, with MEPs and MIPs configured as in production. The bed is looped on itself first: zero CCM loss, DM within a microsecond of the reference, LM equal to the counted loss

Far end

A second test unit at the far end is a peer that raises RDI on cue, and gives one-way 1DM when a common clock is agreed for the project. A WAN emulator in front of it adds known delay and loss, so DM and LM have a figure to be compared with. For a single device the far end is its own peer MEP

Rates and scale

1 GbE, 10 GbE and 100 GbE ports. CCM at 3.3 ms across many MEPs is a load of its own; we agree the MEP count and the levels in the plan and report the number the device held without a missed interval

Parameters

What is fixed before the run

Y.1731 defines the frames and the intervals; the operator chooses levels, rates and thresholds. The plan lists each one, with the value we use when the design is silent

Parameter Our default Allowed Why it matters
MEG levels2 operator, 4 provider, 6 customer0 to 7, any assignmentEach level must answer its own OAM and pass the higher one untouched; a wrong level filter breaks the customer's view
CCM interval3.3 ms for protection, 100 ms for monitoring3.3 ms, 10 ms, 100 ms, 1 s, 10 s, 1 min, 10 minSets the detection time: loss of continuity comes 3.5 intervals after the last CCM, so 3.3 ms gives 11.7 ms and 100 ms gives 350 ms
MEP countYour design count, agreed in the plan1 to the device limitCCM at 3.3 ms costs hardware timers or CPU; the count the device holds without a missed CCM is a result in itself
OAM prioritySame PCP as the serviceAny PCP, 0 to 7DM and LM frames in a higher queue than the service measure the queue they are in, not the one the customer uses
DM interval and samples1 s, 900 samples100 ms to 10 s, 100 to 86,400 samplesEnough samples to give minimum, average and maximum with a confidence the SLA can quote
Loss measurementLMM/LMR on service counters, SLM/SLR next to itLMM only, SLM only, bothLMM counts real service frames and needs working counters; SLM counts synthetic frames and suits multipoint services. Both must agree with the reference
Background load0, 40, 80, 95 % of line rateAny list of load stepsOAM that works on an idle port may be dropped or delayed when the queues fill; the failures live at the high steps
ThresholdsDetection ≤ 3.5 intervals, DM within 5 % or 100 µs, LM within 0.01 %Per MEG, per metricThe OAM figure is set against the generator's own measurement on the same frames; the tolerance says how wrong the dashboard may be

Frames and intervals are those of Y.1731; the default values are our choice. When the network design names a value, the design wins

Always in our runs

  • CCM in both directions, RDI checked at both MEPs
  • DM and LM next to the generator's own figure
  • Every performance test with and without background load
  • OAM frames at the priority of the service they watch
  • Counters from both MEPs, per level
  • Loopback pre-test of the bed

Both directions of every MEG, every OAM figure beside its reference, every performance test repeated under load. These are the runs that make a Y.1731 report worth signing

Agreed per device or path

  • CCM interval: 3.3 ms, 10 ms, 100 ms or slower
  • MEP count for the scale test
  • One-way 1DM with PTP or GPS, or two-way DMM only
  • SLM/SLR instead of, or next to, LMM/LMR
  • Protection switch, G.8031 or G.8032, with CCM running
  • Soak length: 15 min, 2 h or 24 h

Interval, MEP count, one-way measurement, synthetic loss, protection switching and soak length are set in the plan with you. Each one changes how long the run takes and what the report can claim

Inside the method

Three fault tests, three performance tests

Y.1731 splits into fault management and performance monitoring. We run the fault side first, level by level, then the measurement side under load, because the second only means something once the first is clean

  1. CCMFault

    Continuity check and RDI

    CCM at the agreed interval between every pair of MEPs, both directions, with service traffic running. A link is cut and the time to loss of continuity is measured from the last frame on the wire to the alarm. The peer must raise RDI and clear it when the link returns

    CCM · per MEG level · 3.5 intervals is the limit
  2. LB · LTFault

    Loopback and linktrace

    Unicast and multicast LBM from 64 to 1518 bytes in bursts of 100 to 1000, LTM along the path. Every LBR comes back in order, every MIP answers the linktrace with the right TTL and egress identifier, and OAM at a level a MIP does not own passes through unanswered

    LBM/LBR · LTM/LTR · per level, per MIP
  3. AIS · LCKFault

    AIS, lock and interop

    A fault at the operator level must raise AIS towards the client level above it and nowhere else. With two vendors on the MEG we check that CCM, RDI, AIS and the lock signal are read the same way on both sides, and that an unknown TLV is ignored, not taken as a fault

    AIS · LCK · two vendors, two directions
  4. DMPerformance

    Frame delay: DMM/DMR and 1DM

    Two-way delay from DMM/DMR and, with a common clock at both ends, one-way delay from 1DM, at each background load step. The OAM figure is set against the delay the generator measured on service frames in the same second; the gap is the result

    DMM/DMR · 1DM · 0 to 95 % load
  5. LM · SLMPerformance

    Frame loss: LMM/LMR and SLM/SLR

    LMM/LMR on the real service counters and SLM/SLR on synthetic frames, with the WAN emulator dropping a known 0.1 % and then 1 %. Near-end and far-end loss must match the reference in both directions

    LMM/LMR · SLM/SLR · known impairment
  6. SCALEPerformance

    Scale, load and protection

    The agreed number of MEPs at 3.3 ms and 10 ms for the whole soak, with the port at 95 % load; then a G.8032 ring or G.8031 linear switch with CCM running. No missed CCM, no false loss of continuity, and the switch time recorded against the target

    MEP scale · 95 % load · G.8031 / G.8032

Procedure

From the plan to the signature

A device with three MEG levels on a 10 GbE port takes one to two bench days: the fault side in the morning, the measurement side with a two-hour soak after

  1. 00

    Test plan

    MEG levels, MEP count, CCM interval, OAM priority, load steps, the measurements and every threshold in one table, signed off by both sides before anything is cabled

  2. 01

    Bed check

    Generator MEP to generator MEP through the test optics: zero CCM loss at 3.3 ms, DM within a microsecond of the reference, LM equal to the counted loss. The device goes in only after that

  3. 02

    Fault side

    Level by level: CCM and RDI with a link cut, loopback and linktrace, AIS and lock across levels, interop with the second vendor when there is one. Each detection time is measured on the wire

  4. 03

    Performance under load

    DM and LM at every load step, then the soak with the full MEP count and the protection switch. Every OAM result is logged beside the reference figure from the same second

  5. 04

    Report and hand-over

    Pass or fail per level and per test, detection times, DM and LM against the reference at each load step, the switch time, with series and raw counters attached. A failed test comes with the queue, the level or the frame behind it

ONE RUN · FAULT SIDE FIRST, THEN PERFORMANCE UNDER LOAD EVERY OAM FIGURE NEXT TO THE REFERENCE FAULT MANAGEMENT · PER MEG LEVEL CCM · LB · LT · AIS · RDI LEVEL 2 LEVEL 4 LEVEL 6 CCM 3.3 ms LBM ×100 LTM CUT · LOC RDI AIS UP CCM 10 ms LBM ×100 LTM CUT · LOC RDI AIS UP CCM 100 ms PASSES LEVEL 2, 4 AIS FROM LEVEL 4 NO FALSE LOC PERFORMANCE · DM AND LM LOAD 0 · 40 · 80 · 95 % DMM LMM SLM 0 %40 %80 %95 % two-way delay against the reference, each load step counted loss against the reference, 0.1 % impaired synthetic loss, 15 min to 24 h, availability LOC WITHIN 3.5 INTERVALS = DETECTION WORKS DM AND LM EQUAL TO THE REFERENCE = TRUSTED COUNTERS OAM DROPPED OR WRONG UNDER LOAD = NOT SLA READY

One run: the fault side per level first, then delay and loss at four load steps. The pass rules are the same for every level

Pass rules we apply

  • ≤ 3.5 ×

    Loss of continuity declared within 3.5 CCM intervals of the last frame on the wire, at every level, in both directions, with RDI at the peer

  • ± 5 %

    Delay from DMM, DMR or 1DM within 5 % or 100 µs of the generator's own measurement on the service frames, at every load step

  • 0.01 %

    Loss from LMM or SLM within 0.01 % of the loss the generator counted on the same frames, near end and far end, both directions

  • 0 missed

    No CCM missed and no false loss of continuity through the soak at full MEP count and 95 % load, the protection switch included

Time budget

  • Bed check10 minutes, once per set of optics and cables
  • Fault side1 to 2 hours for three levels with one link cut per level; a second vendor adds an hour
  • Performance and soak4 load steps in under an hour, then 15 minutes for a quick device check, 2 hours as our default, 24 hours when the SLA quotes daily availability
  • ReportSame day for a 2 h soak, the next day for 24 h

Report

What you get at the end

A verdict per level and per test, with every OAM figure beside the reference it was compared with. Enough to accept the device, or to show the vendor the queue and the frame

Per MEG level

  • Detection time per link cut: last CCM on the wire to loss of continuity, and to RDI at the peer
  • LBR and LTR returned, in order, per MIP and per frame size
  • DM from the device and from the reference at each load step: minimum, average, maximum
  • LM and SLM against the counted loss, near end and far end
  • Missed CCMs and false alarms through the soak
  • Pass or fail against each threshold

Context

  • MEP and MIP table: level, interval, priority, direction
  • Bed check result with the optics and cables used
  • Sync source for one-way measurement and its offset
  • Load steps and the impairment set on the emulator
  • Timestamps of every cut, switch and load step
  • Firmware and software versions of the device and the test units
Y.1731 · OAM REPORT 10 GbE NID · 3 LEVELS · 2 h CCM64 MEPs at 3.3 ms, detection CCM500 MEPs at 10 ms, detection LBLBM 1518 B ×1000, level 4 LTLTM along the path DMDMM two-way, idle DMDMM two-way, 80 % load LMLMM against counted loss PSG.8032 switch, CCM 3.3 ms 11.4 ms 34 ms 0 lost 3 hops 0.21 ms 0.8 ms 0.10 % 38 ms limit 11.7 ms · RDI at the peer within 1 interval limit 35 ms · no CCM lost over 2 h 1000 LBR back, in order LTR from each MIP · TTL decremented reference 0.20 ms · difference 10 µs reference 4.1 ms · OAM at PCP 7, service at PCP 3 reference 0.10 % · both ends agree no false LOC during the switch ATTACHED MEP TABLE DM · LM SERIES DETECTION LOG COUNTERS · PCAP Values are illustrative. Your report carries your MEPs, intervals and SLA thresholds

Attached

  • One-second DM and LM series per level as CSV, device and reference side by side
  • Raw counters from both MEPs and a PCAP around every cut and switch
  • Detection timeline graphs as PNG, ready for the acceptance document

From practice

The dashboard that was right on an idle port and wrong under load

A demarcation device for business access, three MEG levels, CCM at 3.3 ms. Every fault test passed: detection at 11.4 ms, RDI and AIS where they belonged, loopback and linktrace clean. Delay measurement passed too on an idle port: 0.21 ms from the device, 0.20 ms from the generator. At 80 % background load the device still reported 0.8 ms. The generator measured 4.1 ms on the service frames in the same second.

The DMM frames were sent at PCP 7, the service ran at PCP 3. Under load the OAM frames skipped the queue the customer was waiting in, so the portal would have shown a fifth of the real delay. The fix was one line of configuration: OAM at the service priority. The rerun gave 4.0 ms against 4.1 ms, and the SLA report could be trusted.

Y.1731 delay measurement on a 10 GbE demarcation device, 80 % load, PCP 7 against PCP 3

SAME PATH · TWO-WAY DELAY AT 80 % LOAD REPORTED BY THE NID · DMM AT PCP 7 OAM frames jump the queue the service waits in 0.8 ms MEASURED BY THE GENERATOR · PCP 3 Timestamped service frames, the customer's queue 4.1 ms AFTER THE FIX · DMM AT PCP 3 4.0 ms OAM in the service queue: the dashboard shows what the customer gets

Services

How we run Y.1731 for you

On our CloudLAB bench against your device, or on your path with our units at both ends. Same plan, same report

Device acceptance

A NID, switch or PE before it goes to hundreds of sites: fault side, measurement side, scale and the protection switch, against the thresholds your SLA will quote

Order a device run

Interop between vendors

Both ends of the MEG on the bench, each at its level. CCM, RDI, AIS and the measurement frames read the same way on both sides, or the report says where they differ

Bring both devices

SLA dashboard validation

Your path, our units at the ends, your real OAM configuration. The portal's delay and loss against an independent measurement, under the load the service carries

Ask for a path check

Recurring checks

The same plan rerun after a firmware change or a new OAM profile, with the previous report as the baseline

Set up a schedule
  • Report in the Y.1731 structure, fault side and performance side, level by level
  • Test units with MEP emulation at 1G, 10G and 100G, and a WAN emulator for known delay and loss
  • Engineers who read the OAM design before the counters

Related pages

FAQ

Questions we get about Y.1731

How is Y.1731 different from Y.1564?

Y.1564 activates a service: it loads every class to its CIR and EIR for a set time and says whether the SLA holds on that day. Y.1731 is the OAM that watches the service afterwards: continuity, loopback, linktrace, alarms and the delay and loss frames behind the dashboard. We test Y.1731 so the figures the operator reports every day are as trustworthy as the activation report.

Is this the same as IEEE 802.1ag?

The fault side mostly is: 802.1ag (CFM) defines maintenance domains, MEPs, MIPs, continuity check, loopback and linktrace, and Y.1731 uses the same frame format and adds AIS, lock, test frames and the performance measurements. A device that claims 802.1ag only is tested on the fault side; a device that claims Y.1731 or G.8013 is tested on both.

Do we need a common clock?

Only for one-way delay with 1DM, which needs the same clock at both ends. Two-way DMM/DMR, loss measurement and every fault test work without sync. If your SLA quotes one-way delay, the clock source is agreed per project; if it quotes round trip, a peer MEP is enough.

Why compare OAM with the generator at all?

Because OAM measures itself. A DMM frame reports the delay that DMM frame saw; if it travels in another queue, on another path or at another priority than the service, it reports a different network. The generator timestamps the service frames, so the report shows the OAM figure and the real figure for the same second, and the gap is the finding.

How many MEPs at 3.3 ms are tested?

We fix the target in the plan and check that the test units hold it at the chosen rate before the run. In practice the ceiling is the device: CCM at 3.3 ms needs hardware timers, and the count a device holds without a missed interval is one of the numbers in the report. We go past the target until the first miss.

What happens when a test fails?

The run goes on and the test is marked failed with the level, the load step and the frame or queue behind it. You change the configuration or the firmware, we rerun that test and the ones that depend on it, and the report shows both results.

Test plan and quote in 1 to 3 business days

Send the OAM design, the MEG levels and the SLA figures the portal must report. You get the plan with every parameter and threshold, the run length and a quote for the run

Request a Y.1731 plan Log in to CloudLAB

Send the shortlist

You have the method. Now get the numbers.

Name the models and the KPIs that matter. An engineer replies within one business day with a test plan draft and a quote.

Prefer to chat? Message an engineer on WhatsApp

We use what you send only to answer you. See our Privacy Policy.