Ethernet Link OAM provides the following benefits:

• Competitive advantage for service providers.

• Standardized mechanism to monitor the health of a link and perform diagnostics.

Discovery is the first phase of Ethernet link OAM where it identifies the devices in the network and their OAM capabilities. Discovery uses information OAM PDUs. During the discovery phase, the following information is advertised within periodic information OAM PDUs:

• OAM mode—Conveyed to the remote OAM entity. The mode can be either active or passive and can be used to determine device functionality.

• OAM configuration (capabilities)—Advertises the capabilities of the local OAM entity. With this information a peer can determine what functions are supported and accessible; for example, loopback capability.

• OAM PDU configuration—Includes the maximum OAM PDU size for receipt and delivery. This information along with the rate limiting of 10 frames per second can be used to limit the bandwidth allocated to the OAM traffic.

• Platform identity—Specifies a combination of an organization unique identifier (OUI) and 32-bits of vendor-specific information. OUI allocation, controlled by the IEEE, is typically the first three bytes of a MAC address.

Discovery includes an optional phase in which the local station can accept or reject the configuration of the peer OAM entity. For example, a node may require its partner support loopback capability to be accepted in the management network. These policy decisions may be implemented as vendor-specific extensions.

Link monitoring in Ethernet Link OAM detects and indicates link faults under a variety of conditions. Link monitoring uses the event notification OAM PDU and sends events to the remote OAM entity when there are problems detected on the link. The error events include the following:

• Error Frame (error frames per second)—The number of frame errors detected during a specified period that exceed a threshold.

• Error Frame Period (error frames per n frames)—The number of frame errors within the last n frames that exceed a threshold.

• Error Frame Seconds Summary (error seconds per m seconds)—The number of error seconds (1-second intervals with at least one frame error) within the last m seconds that exceed a threshold.

Because IEEE 802.3ah OAM does not provide a guaranteed delivery of any OAM PDU, the event notification OAM PDU may be sent multiple times to reduce the probability of a lost notification. A sequence number is used to recognize duplicate events.

Faults in Ethernet connectivity that are caused by slowly deteriorating quality are difficult to detect. Ethernet Link OAM provides a mechanism for an OAM entity to convey these failure conditions to its peer via specific flags in the OAM PDU. The following failure conditions can be communicated:

• Link Fault–Loss of signal is detected by the receiver. A link fault is sent every second in the information OAM PDU. Link fault applies only when the physical sublayer is capable of independently transmitting and receiving signals.

• Dying Gasp–An unrecoverable condition has occurred; for example, a power failure. This type of condition is vendor specific. A notification about the condition may be sent immediately and continuously.

• Critical Event–An unspecified critical event has occurred. This type of event is vendor specific. A critical event may be sent immediately and continuously.

An OAM entity can put its remote peer into loopback mode using the loopback control OAM PDU. Loopback mode helps an administrator ensure the quality of links during installation or when troubleshooting. In loopback mode, every frame received is transmitted back on the same port except for OAM PDUs and pause frames. The periodic exchange of OAM PDUs must continue during the loopback state to maintain the OAM session.

The loopback command is acknowledged by responding with an information OAM PDU with the loopback state indicated in the State field. This acknowledgement allows an administrator, for example, to estimate if a network segment can satisfy a service-level agreement. Acknowledgement makes it possible to test delay, jitter, and throughput.

When an interface is set to the remote loopback mode the interface no longer participates in any other Layer 2 or Layer 3 protocols; for example Spanning Tree Protocol (STP) or Open Shortest Path First (OSPF). This is because when two connected ports are in a loopback session, no frames other than the OAM PDUs are sent to the CPU for software processing. The non-OAM PDU frames are either looped back at the MAC level or discarded at the MAC level.

From a user perspective, an interface in a loopback mode is in a link-up state.

IEEE CFM is an end-to-end per-service Ethernet layer OAM protocol that supports provider edge-to-provider edge (PE-to-PE) and customer edge-to-customer edge (CE-to-CE) services. A service is identified as an Ethernet virtual circuit (EVC) service.

Troubleshooting carrier networks offering Ethernet Layer 2 services is challenging. Customers contract with service providers for end-to-end Ethernet service and service providers may subcontract with operators to provide equipment and networks. Compared to enterprise networks, where Ethernet traditionally has been implemented, these constituent networks belong to distinct organizations or departments, are substantially larger and more complex, and have a wider user base. Ethernet CFM provides a competitive advantage to service providers for which the operational management of link uptime and timeliness in isolating and responding to failures is crucial to daily operations.

• End-to-end service-level OAM technology.

• Reduced operating expense for service provider Ethernet networks.

• Competitive advantage for service providers.

• Support for both distribution and access network environments with Down (toward the wire) MEPs.

MEPs reside at the edge of a maintenance domain and are active elements of CFM. They confine CFM messages within the domain through the maintenance domain level. MEPs periodically transmit and receive continuity check messages (CCMs) from other MEPs within the domain. MEPs also transmit linktrace and loopback messages at the request of the administrator.

MEP ID uniquely identifies each MEP along with those configured on a single MA. The MEP IDs range from 1 to 8191.

There are two types of MEPs:

• Up (inwards, toward the bridge). This is the default.

• Down (outwards, toward the wire).

MEP supports multicast loopbacks and pings. When a multicast ping is initiated for a particular domain or service, all the related remote MEPs reply to the ping.

MEP configurations can be removed after all pending loopback and linktrace replies are removed and the service on the interface is set to transparent mode. To set the service to transparent mode, MIP filtering must not be configured.

An Up MEP is an MEP that resides in a bridge and transmits to and receives CFM messages from the direction of the bridge relay entity.

An Up MEP performs the following functions:

• Sends and receives CFM frames at its level through the bridge relay and not through the wire connected to the port on which the MEP is configured.

• Drops all CFM frames at its level (or lower level) that come from the direction of the wire.

• Processes all CFM frames at its level coming from the direction of the bridge.

• Drops all CFM frames at a lower level coming from the direction of the bridge.

• Forwards all CFM frames transparently at a higher level, independent of whether they came in from the bridge or wire.

A Down MEP is an MEP that resides in a bridge and transmits to and receives CFM messages from the direction of the wire.

A Down MEP performs the following functions:

• Sends and receives CFM frames at its level through the wire connected to the port where the MEP is configured.

• Drops all CFM frames at its level (or at a lower level) that come from the direction of the bridge.

• Processes all CFM frames at its level coming from the direction of the wire.

• Drops all CFM frames at a lower level coming from the direction of the wire.

• Forwards all CFM frames transparently at a higher level, independent of whether they came in from the bridge or wire.

CPT also supports Port MEP at the physical port. A port MEP can be created either on the physical port or on the port of a channel group. The port MEP takes higher precedence if both the port MEP and the Down MEP on untagged EFP is created on the same port.

The cross-check function is a timer-driven post-provisioning service verification between dynamically discovered MEPs (through CCMs) and expected MEPs (through configuration) for a service. The cross-check function verifies that all the endpoints of a multipoint or point-to-point service are operational. The function supports notifications when the service is operational; otherwise it provides alarms and notifications for unexpected or missing endpoints.

You must initiate the cross-check function each time you want a service verification. See DLP-J323 Configure Cross-Check for an MEP Using Cisco IOS Commands.

CFM continuity check messages (CCMs) are multicast heartbeat messages exchanged periodically among MEPs. They allow MEPs to discover other MEPs within a domain and allow MIPs to discover MEPs. CCMs are confined to a domain.

CFM CCMs have the following characteristics:

• Transmitted at a periodic interval by MEPs. The interval can be one of the following configurable values. The default is 10 seconds.

  • 100 milliseconds

  • 1 second

  • 10 seconds

  • 1 minute

  • 10 minutes

• Cataloged by MIPs at the same maintenance level.

• Terminated by remote MEPs at the same maintenance level.

• Unidirectional and do not solicit a response.

• Indicate the status of the bridge port on which the MEP is configured.

CFM loopback messages (LBMs) are unicast frames that an MEP transmits, at the request of an administrator, to verify connectivity to a specific maintenance point. A loopback message reply (LBR) indicates whether a destination is reachable but does not allow hop-by-hop discovery of the path. A loopback message is similar in concept to an Internet Control Message Protocol (ICMP) Echo (ping) message.

Since LBMs are unicast messages, they are forwarded like normal data frames except with the maintenance level restriction. If the outgoing port is known in the forwarding database of the bridge and allows CFM frames at the maintenance level of the image to pass through, the frame is sent out on that port. If the outgoing port is unknown, the message is broadcast on all the ports in that domain.

A CFM LBM can be generated on demand using the CLI. The source of a loopback message must be an MEP; the destination may be an MEP or MIP. Both CFM LBMs and LBRs are unicast. CFM LBMs specify the destination MAC address or MPID, VLAN, and maintenance domain.

CFM linktrace messages (LTMs) are multicast frames that an MEP transmits, at the request of an administrator, to track the path (hop-by-hop) to a destination MEP. They are similar to Layer 3 traceroute messages. LTMs allow the transmitting node to discover vital connectivity data about the path and allow the discovery of all MIPs along the path that belong to the same maintenance domain. LTMs are intercepted by maintenance points along the path and processed, transmitted, or dropped. At each hop where there is a maintenance point at the same level, a linktrace message reply (LTR) is transmitted back to the originating MEP. For each visible MIP, linktrace messages indicate ingress action, relay action, and egress action. LTMs are multicast and LTRs are unicast.

• DLP-J352 Lock an MEP or an Interface Using CTC