High-performance Ethernet OAM ITU-T Y.1731 for VLNC42/42B circuit packs

Overview

The VLNC42/42B circuit pack supports high-performance Ethernet OAM ITU-T Y.1731 to provide fault and performance management for service providers in large Ethernet networks.

ITU-T service OAM standard Y.1731 is similar to IEEE standard 802.1ag in that it divides a network into maintenance domains in the form of hierarchy levels. Both of these are then allocated to users, service providers, and operators. Connectivity Fault Management (CFM) assigns maintenance end points (MEPs) to the edges of each domain and maintenance intermediate points (MIPs) to ports within domains. This defines the relationships between all entities from a maintenance perspective to allow each entity to monitor the layers under its responsibility and easily localize problems.

The VLNC42/42B circuit packs support the following High-performance Ethernet OAM ITU-T Y.1731 features:

Service OAM PM

The VLNC42/42B circuit packs support the following Service OAM PM features:

Architecture

All Customer Port OAM is implemented in the FPGA device at the Network port as shown in the following figure.

Figure 5-7: Y.1731 OAM PM architecture
Y.1731 OAM PM architecture

The FPGA device provides Y.1731 functionality for customer port Up-MEPs and network port Down-MEPs. The received OAM frames that are processed by the FPGA are terminated in the MEP and do not propagate towards the switch. In the (network port) transmit direction, OAM frames are merged with data frames in the FPGA. This introduces a store-and-forward buffer in that direction, which adds some latency and jitter, which is not measured by the delay measurement.

Loss measurement (LM)

Loss Measurement provides an accurate accounting of frames received versus frames sent for a service. A typical use is by a Service Provider who conducts the measurement proactively (continuously) end-to-end for Service Level Agreement (SLA) verification. Up-MEPs at the service endpoints exchange frame count information to make the calculation. The customer can do the same in their equipment for the same reason, using Down-MEPs on their UNI ports. If the service crosses administrative boundaries, then the responsible entities may measure performance on each leg, bounded by their MEPs.

Alcatel-Lucent 1850 TSS-5 supports the following types of loss measurements:

Frame Loss Ratios (FLRs) are reported with 10-9 precision. TCAs are configurable for Avg and Max FLR, SES and UAS.

Proactive

Proactive loss measurement (Dual-Ended: CCM-based) is used to monitor Severely Errored Seconds (SES) and Unavailable Seconds (UAS), also for SLA verification. A Frame Loss Ratio (FLR) is calculated each second, and if it exceeds 75%, (or if the MEP detects a local fault) then the SES counter is incremented. UAS is calculated in the same manner as in TDM. Both are implemented according to ITU-T G.7710.

The following proactive LM details are retrievable by the user via SNMP and are retrieved per direction:

Synthetic frame LM using fast CCM

In some cases it is not possible to measure loss directly on service frames, for example for multipoint or when using some protection schemes. Instead, a separate VLAN is used to follow a representative path, and synthetic “data” frames sent instead of user data. If the synthetic frame rate is fast enough, and the monitoring period long enough, a statistically significant loss measurement to a desired precision can be estimated. Fast CCM can be used to provide the synthetic data frames. When a MEP is configured at a higher level (level 4) than the one which will do the loss measurement ( level 1), its CCM frames are counted by the LM process of the lower level MEP. The CCM interval range includes 100 msec and 10 msec. The interval range provides rates of synthetic frames that are suitable for a wide range of accuracy/measuremnt interval combinations.

On-Demand

On-Demand loss measurements (Single-Ended: LMM/LMR-based) provide a troubleshooting tool. It consists of the Frame Loss Ratio (FLR) measured over a specified interval at a specified time.

Per direction:

For the session:

Delay measurement (DM)

Proactive Delay and Delay Variation measurements are typically done for service level agreement verification (SLA), and so may be used simultaneously used with Loss Measurement for the same services.

Delay is measured by synthetic frames using probe messages rather than measured directly on data frames. This allows for measuring two-way or round-trip (RT) delay using initiator and responder frames, which can be done without synchronizing clocks between endpoints. The responder reflects the initiator’s probe frame the initiator timestamps the frame when sent, and again when the reflection is received. The closer timestamps are to the actual sending and receiving of the frames, the more accurate the measurement. The difference between the timestamps is the RT delay, including the time it takes the responder to reflect the message.

The responder also timestamps the message when received and again when reflected. The initiator can use the responder’s timestamps to obtain its processing interval, and subtract that from the RT delay to get a better measure of the delay experienced by data traffic.

Two-way (round trip) delay measurement

Two-way DM uses DMM and DMR frames for both Proactive and On-Demand measurements. Timestamps are inserted into these frames as described above. The initiator stamps the outgoing DMM. The destination stamps it when received, then swaps DA and SA and changes the opcode to make it a DMR, and stamps it again as it is sent back to the initiator. The initiator stamps it when received, and then processes the four timestamps. DM frames are tagged (VID required) and delay is always measured for a specific priority. Like LM, DM uses a limited resource so that a configured responder is necessary to support a remote DM session (Proactive or On-Demand) when there is not a DM session for the same VLAN, CoS and MD level (and port, for a Down-MEP) enabled on the MEP. DM does not depend on CCM. If the DA is unknown then DMM are broadcast the same as data frames. However, because the delay measurement is only defined for point-to-point, DMRs from multiple peers may yield unusable results.

The following two-way DM details are retrievable by the user via SNMP and are retrieved per direction:

The above measurements have 0.1 msec precision.

One-way delay variation measurement (no Synchronized ToD clock needed)

One-way delay variation is calculated by differences between neighboring “one-way delay” measurements to minimize the error due to frequency offset between clocks used by peers. Only next-neighbors (distance 1) are used to calculate the difference.

The following one-way delay variation measurements are retrievable by the user via SNMP and are retrieved per direction:

The above measurements have 0.1 msec precision.

A TCA is configurable for Avg and Max Delay Variation.

One-way delay measurement (Synchronized ToD clock needed)

One-way delay measurement in the forward direction is obtained by subtracting the initiator Tx timestamp from the responder Rx timestamp as found in the DMR. The other two timestamps are used for one-way delay in the backward direction. Accurate one-way delay measurement requires closely aligned ToD clocks at each MEP. Because 1588v2 is used for alignment, it is difficult to quantify the achievable accuracy in any particular deployment. The 1588v2 protocol is sensitive to many factors, including directional delay asymmetry, FDV, and local clock accuracy. Asymmetry is largely determined by the network configuration and the NEs in the path, and whether they have Transparent Clock capability. FDV is affected by the traffic load both in volume and burstiness. Local clock accuracy is a factor if SYNC-E is not employed. In that case the VLNC42B is preferred because it has a temperature compensated oscillator, and the VLNC42 does not

The following one-way delay measurements are retrievable by the user via SNMP and are retrieved per direction:

A TCA is configurable for Avg and Max Delay.

Ethernet AIS

Ethernet AIS is similar to SONET/SDH AIS. It is used to convey fault information forward so that downstream MEPs can avoid declaring actionable alarms for the same fault.

AIS insertion may be enabled on any MEP except on a port which has spanning tree or ERP enabled. Ethernet AIS is inserted into a configured client MD level, in the direction opposite of other MEP OAM transmission. Because AIS processing is done in software, frames are only sent at 1-minute periods (with a three-frame burst on initiation).

AIS detection on a MEP is used to suppress Loss of Continuity (LOC) alarms. It also may trigger AIS if the detecting MEP is enabled to do so. In this way the cascade behavior is obtained even if the detecting MEP does not run Continuity Check Messages (CCM). AIS detection is alarmed. AIS detection is not configurable and all MEPs can detect AIS.

If AIS is to be used in the network, all MEPs should be enabled for AIS generation. The client MD level of the next configured MD can also be provisioned so that AIS cascades to suppress all secondary alarms. An exception is a Down-MEP on a UNI-N port. In this case the client level may be that of a Customer ME (because Up-MEPs at Provider or Operator levels do not experience secondary alarms due to an LOS at the UNI-N.)

Y.1731/G.8021 Continuity Check Message (CCM) alarms

G.8021 splits two of the 802.1ag Continuity Check Message (CCM) defects into four components. Some of the components are used to trigger AIS. It splits the 802.1ag loss of continuity defect into individual LOC indications for each remote MEP. It also adds a defect for receiving a CCM with a different priority than configured.

A list of the G.8021 CCM defects include the following:

Copyright © 2011 Alcatel-Lucent. All rights reserved.