It is important to note that AIS operates independently from the low-priority-defect setting. The low-priority-defect setting configuration parameter affects only the ETH-CFM fault propagation and alarming outside the scope of AIS. By default, an fault in the CCM MEP state machine generates AIS when it is configured. Table: Defect conditions and priority settings illustrates the ETH-CC defect condition groups, configured low-priority-defect setting, priority and defect as it applies to fault propagation. AIS maintains its own low-priority-defect option which can be used to exclude the CCM defect RDI from triggering the generation of AIS.
| Defect | Low priority defect | Description | Causes | Priority |
|---|---|---|---|---|
DefNone |
n/a |
No faults in the association. |
Normal operations. |
n/a |
DefRDICCM |
allDef |
Remote Defect Indication. |
Feedback mechanism to inform unidirectional faults exist. It provides the feedback loop to the node with the unidirectional failure conditions. |
1 |
DefMACStatus (default) |
macRemErrXcon |
MAC Layer. |
Remote MEP is indicating a remote port or interface not operational. |
2 |
DefRemoteCCM |
remErrXon |
No communication from remote peer. |
MEP is not receiving CCM from a configured peer. The timeout of CCM occurs at 3.5x the local CC interval. As per the specification, this value is not configurable. |
3 |
DefErrorCCM |
errXcon |
Remote and local configures do not match required parameters. |
Caused by different interval timer, domain level issues (lower value arriving at a MEP configured with a higher value), MEP receiving CCM with its MEP-ID. |
4 |
DefXconn |
Xcon |
Cross Connected Service. |
The service is receiving CCM packets from a different association. This could indicate that two services have merged or there is a configuration error on one of the SAP or bindings of the service, incorrect association identification. |
5 |
A facility MEP may trigger two distinct actions as a result of fault. Epipe services generate AIS that have been configured to do so as a result of a failure. The level of the AIS is derived from the facility MEP. Multiple client-meg-levels can be configured under the facility MEP to allow for operational efficiency in the event a change is required. However, only the lowest AIS level is generated for all the linked and applicable services. VPLS, IES and VPRN SAPs transition the SAP state that are configured to react to the facility MEP state. In addition, Epipe services may also take advantages of OAM and mapping functions.
Before implementing facility MEPs, it is important to understand the behavior of AIS and Fault propagation. Nokia advises considers the following recommendations listed below before enabling or altering the configuration of any facility MEP. These steps must be tested on each individual network before building a maintenance operational procedure (MOP).
Do not configure AIS on the facility MEP until the ETH-CCM has been verified. For instance, when a local MEP is configured with AIS before the completion of the remote MEP, the AIS is immediately generated when the MEP enters a fault state for all services linked to that facility MEP.
Disable the client-meg-level configuration parameter when changes are being made to existing functional facility MEPs for AIS. Doing this stops the transmit function but maintains the ability to receive and understand AIS conditions from the network.
Set the low-priority-defect parameter to noXconn to prevent the MEP from entering a defect state, triggering SAP transitions and OAM mapping reactions.
It is important to consider and select what types of fault conditions causes the MEP to enter a faulty state when using fault propagation functions.
The ccm-hold-timers supported on port-based MEPs configured with a sub-second interval. The ccm-hold-timers prevents the MEP from entering a failed state for 3.5 times the CCM interval plus the additional hold timer.