802.3ah OAM

802.3ah Clause 57 (EFM OAM) defines the Operations, Administration, and Maintenance (OAM) sublayer, which provides mechanisms useful for monitoring link operation such as remote fault indication and remote loopback control. In general, OAM provides network operators the ability to monitor the health of the network and quickly determine the location of failing links or fault conditions. EFM OAM described in this clause provides data link layer mechanisms that complement applications that may reside in higher layers.

OAM information is conveyed in slow protocol frames called OAM protocol data units (OAMPDUs). OAMPDUs contain the appropriate control and status information used to monitor, test, and troubleshoot OAM-enabled links. OAMPDUs traverse a single link being passed between peer OAM entities, and therefore, are not forwarded by MAC clients (like bridges or switches).

The following EFM OAM functions are supported:

  • EFM OAM capability discovery

  • active and passive modes

  • remote failure indication mechanism to handle critical link events, including link fault and dying gasp

  • dying gasp support; EFM OAM dying gasp messages and SNMP dying gasp messages are mutually exclusive and are generated on power failure. See the 7210 SAS-Mxp, R6, R12, S, Sx, T System Management Guide for more information about support for SNMP dying gasp.

    All 7210 SAS platforms process the EFM OAM dying gasp message received on a port enabled for EFM and generate an SNMP trap. Support for generation of dying gasp messages on 7210 SAS platforms is listed in the following table.

    Table 1. Dying gasp message support on 7210 SAS platforms

    7210 SAS platform

    Dying gasp message support 1

    7210 SAS-Mxp

    ✓

    7210 SAS-R6

    7210 SAS-R12

    7210 SAS-Sx/S 1/10GE

    ✓

    7210 SAS-Sx 10/100GE

    ✓

    7210 SAS-T

    ✓
    1 EFM OAM dying gasp messages are generated on either the network ports or access uplink ports based on the operating mode of the device. The messages are not generated on access ports.

  • loopback, a mechanism provided to support a data link layer frame-level loopback mode. Both remote and local loopback modes are supported.

  • EFM OAMPDU tunneling

  • high resolution timer for EFM OAM in 500ms interval (minimum)

OAM events

EFM OAM defines a set of events that may impact link operation. The following critical link events (as defined in 802.3ah clause 57.2.10.1) are supported:

  • link fault

    The PHY has determined a fault has occurred in the receive direction of the local DTE.

  • dying gasp

    An unrecoverable local failure condition has occurred.

  • critical event

    An unspecified critical event has occurred.

These critical link events are signaled to the remote DTE by the flag field in OAM PDUs.

The 7210 SAS does not generate EFM OAM PDUs with these flags except for the dying gasp flag. However, it supports processing of these flags in EFM OAM PDUs received from the peer.

Remote loopback

EFM OAM provides a link-layer frame loopback mode that can be remotely controlled.

To initiate remote loopback, the local EFM OAM client sends a loopback control OAM PDU by enabling the OAM remote-loopback command. After receiving the loopback control OAM PDU, the remote OAM client puts the remote port into local loopback mode.

To exit remote loopback, the local EFM OAM client sends a loopback control OAM PDU by disabling the OAM remote-loopback command. After receiving the loopback control OAM PDU, the remote OAM client puts the port back into normal forwarding mode.

Note that during remote loopback test operation, all frames except EFM OAM PDUs are dropped at the local port for the receive direction, where remote loopback is enabled. If local loopback is enabled, then all frames except EFM OAM PDUs are dropped at the local port for both the receive and transmit directions. This behavior may result in many protocols (such as STP or LAG) resetting their state machines.

802.3ah OAM PDU tunneling for Epipe service

The 7210 SAS routers support 802.3ah. Customers who subscribe to Epipe service treat the Epipe as a wire, so they demand the ability to run 802.3ah between their devices which are located at each end of the Epipe.

Note:

This feature only applies to port-based Epipe SAPs because 802.3ah runs at the port level, not at the VLAN level. Therefore, such ports must be configured as null encapsulated SAPs.

When OAM PDU tunneling is enabled, 802.3ah OAM PDUs received at one end of an Epipe are forwarded through the Epipe. 802.3ah can run between devices that are located at each end of the Epipe. When OAM PDU tunneling is disabled (by default), OAM PDUs are dropped or processed locally according to the efm-oam configuration (shutdown or no shutdown).

Note that by enabling 802.3ah for a specific port and enabling OAM PDU tunneling for the same port are mutually exclusive.