Configuring Ethernet OAM Ethernet OAM Overview
OmniSwitch AOS Release 7 Network Configuration Guide June 2013 page 35-5
Fault Management
Service OAM Connectivity Fault Management consists of three types of messages that are used to help
network administrators detect, verify, and isolate when a problem occurs in the network:
• Continuity Check Messages (CCM)—These are multicast messages exchanged periodically by MEPs
to detect loss of service connectivity between MEPs. These messages are also used by MEPs and MIPs
to discover other MEPs within a domain.
• Linktrace Messages (LTM)—These messages are transmitted by a MEP to trace the path to a destina-
tion maintenance point. The receiving maintenance point responds to LTMs with a linktrace reply
(LTR). This mechanism is similar to the UDP Trace Route function. The transmission of linktrace
messages is requested by an administrator.
• Loopback Messages (LBM)—These messages are transmitted by a MEP to a specified MIP or MEP
to determine whether or not the maintenance point is reachable. The receiving maintenance point
responds to LBMs with a loopback reply (LBR). This mechanism is not used to discover a path to the
destination; it is similar to the Ping function. The transmission of loopback messages is requested by an
administrator.
Remote Fault Propagation
Remote Fault propagation (RFP) propagates connectivity fault events into the interface that is attached to
a MEP. Once the fault is detected for a MEP, the MEP's interface is shutdown. The feature is configurable
on per MEP basis and is supported only for UP MEPs. It detects only loss of connectivity and remote
MAC defect.
MIP CCM Database Support
Per section 19.4 of the IEEE 802.1ag 5.2 draft standard, an MHF may optionally maintain a MIP CCM
database as it is not required for conformance to this standard. A MIP CCM database, if present, main-
tains the information received from the MEPs in the MD and can be used by the Linktrace Protocol.
This implementation of Ethernet OAM does not support the optional MIP CCM database. As per section
19.4.4 of the IEEE 802.1ag 5.2 draft standard, LTM is forwarded on the basis of the source learning filter-
ing database. Because the MIP CCM database is not supported in this release, MIPs will not forward LTM
on blocked egress ports.
Performance Monitoring
The ITU-T Y.1731 Recommendation addresses the need to monitor performance to help enforce customer
service level agreements (SLAs). Frame delay (latency) and frame delay variation (jitter) are important
performance objectives, especially for those applications (such as voice) that cannot function with a high
level of latency or jitter.
This implementation of Service OAM supports Ethernet frame delay measurement (ETH-DM) and is
compliant with Y.1731. The ETH-DM feature allows for the configuration of on-demand OAM to
measure frame delay and frame delay variation between endpoints.
Frame delay measurement is performed between peer MEPs (measurements to MIPs are not done) within
the same MA. Although the OmniSwitch implementation of ETH-DM is compliant with ITU-T Y.1731,
delay measurement can be performed for both ITU-T Y.1731 and IEEE 802.1ag MEPs.
Any MEP can initiate or reply to an ETH-DM request, depending on the type of delay measurement
requested. There are two types of delay measurements supported: one-way and two-way.
To Next Page
Loading...
Need help?
General