EFM Fundamentals

EFM supports the following basic functions: OAM discovery, link monitoring, fault notification, and remote loopback. Figure 1 illustrates typical EFM implementation on a network. The customer edge (CE) is a device in a customer equipment room and PE1 is the carrier's device. EFM is used to monitor the link connecting the CE to PE1, allowing a carrier to remotely monitor link connectivity and quality.

Figure 1 Typical EFM network

EFM Discovery

During the discovery process, a local EFM entity discovers and establishes a stable EFM connection with a remote EFM entity. Figure 2 shows the discovery process.

Two EFM entities both working in passive mode cannot establish an EFM connection between them.

Figure 2 EFM discovery

EFM entities at both ends of an EFM connection periodically exchange Information OAMPDUs to monitor link connectivity. The interval at which Information OAMPDUs are sent is also known as a handshake interval. If an EFM entity does not receive any Information OAMPDU from the remote EFM entity within the connection timeout interval, the EFM entity considers the connection interrupted and sends a trap to the NMS. Establishing an EFM connection is a way to automatically monitor physical link connectivity.

Link Monitoring

Monitoring Ethernet links is difficult if network performance deteriorates while traffic is being transmitted over physical links. To resolve this problem, configure the EFM link monitoring function that detects data link layer faults in various environments. EFM entities that are enabled with link monitoring exchange Event Notification OAMPDUs to monitor links.

If an EFM entity receives a minor link event, it sends an Event Notification OAMPDU to notify the remote EFM entity of the event and also sends a trap to an NMS. After receiving the trap on the NMS, an administrator can determine the network status and take necessary measures.

Table 1 lists minor link events and usage scenarios.

**Table 1** Minor link events
Minor Link Event	Description	Usage Scenario
Errored symbol period event	If the number of symbol errors that occur on a device interface during a specified period of time reaches a specified upper limit, the device generates an errored symbol period event, advertises the event to the remote device, and sends a trap to the NMS.	Helps the device detect symbol errors during data transmission at the physical layer.
Errored frame event	If the number of frame errors that occur on a device interface during a specified period of time reaches a specified upper limit, the device generates an errored frame event, advertises the event to the remote device, and sends a trap to the NMS.	Helps the device detect frame errors that occur during data transmission at the data link layer.
Errored frame seconds summary event	An errored frame second is a one-second interval wherein at least one frame error is detected. If the number of errored frames that occur during a specified period of time reaches a specified upper limit on an interface of a device, the device generates an errored frame second summary event, advertises the event to the remote device, and sends a trap to the NMS.	Helps the device detect errored frame seconds that occur during data transmission at the data link layer.

Fault Notification

After the OAM discovery process finishes, two EFM entities at both ends of an EFM connection exchange Information OAMPDUs to monitor link connectivity. When traffic is interrupted because the remote EFM entity fails or becomes unavailable, the faulty EFM entity will send an Information OAMPDU that carries a critical link event. After receiving the notification, the local EFM entity sends a trap to the NMS. An administrator can view the trap on the NMS to determine the link status and take measures to rectify the fault.

Table 2 lists critical link events carried in Information OAMPDUs.

**Table 2** Critical link event
Critical Link Event	Description
Link fault	If a loss of signal (LoS) error occurs because a physical link fails, the local device sends a trap to the NMS.
Dying gasp	If an unexpected status change or event occurs because a remote device or board is reset, the local device sends a trap to the NMS.
Critical event	If an unidentified critical event occurs because a fault is detected using association between the remote EFM entity and a specific feature, the local device sends a trap to the NMS. Remote EFM entities can be associated with bidirectional forwarding detection (BFD) and connectivity fault management (CFM).
Link Loss	If a loss of signal (LoS) error occurs because the interval at which OAMPDUs are sent elapses, the local device sends a trap to the NMS.

Remote Loopback

Figure 3 demonstrates the implementation of remote loopback. When a local interface sends non-OAMPDUs to a remote interface, the remote interface loops the non-OAMPDUs back to the local interface (not to the destination addresses of the non-OAMPDUs). This is remote loopback. An EFM connection must be established to implement remote loopback.

An EFM entity that initiates a loopback request must work in active mode.

EFM remote loopback and port mirroring can be configured simultaneously on an interface of the S5720-EI, S5720-HI, S5730-HI, S5731-H, S5731-S, S5731S-H, S5731S-S, S5732-H, S6720-EI, S6720-HI, S6720S-EI, S6730-H, S6730S-H, S6730-S, and S6730S-S.

Figure 3 Implementation of remote loopback

After remote loopback is enabled, the device discards all the non-OAMPDUs, causing service interruption. It is recommended that you enable remote loopback to check link connectivity and quality before a new network is used or a link fault is rectified. The results help an operator take measures to minimize the impact of remote loopback on services.

The local device computes communication quality parameters, such as the packet loss ratio on the current link based on the number of sent and received packets. Figure 4 shows the process of remote loopback.

Figure 4 Process of remote loopback

If the local device attempts to stop remote loopback, it sends a message to instruct the remote device to disable remote loopback. After receiving the message, the remote device disables remote loopback.

If remote loopback is left enabled, the remote device continues to loop back service data, causing service interruption. To prevent this problem, you can configure a capability to automatically disable remote loopback after a specified timeout interval. After the timeout interval expires, the local device automatically sends a message to instruct the remote device to disable remote loopback.