What are OAM tests?

Connectivity Fault Management

PM session CFM testing is based on Metro Ethernet Forum Specification 35 - Service OAM Performance Monitoring Implementation Agreement, which details a standardized method to test and report network delay and loss using CFM messaging. This testing is performed in Layer 2 networks.

Ethernet Connectivity Fault Management in NSP is implemented based on the IEEE Y.1731 and 802.1ag OAM standards. The standards describe protocols for detecting, isolating, and reporting connectivity faults in an Ethernet network. CFM is a Layer 2 OAM object infrastructure.

To perform CFM testing in NSP, the md-index-range and ma-index-range attributes must be configured on the NE; see the NE documentation.

You can use Ethernet CFM for the following:

path discovery
fault detection
fault isolation
fault notification

The following table describes terms relevant to CFM in NSP.

Term	Expansion	Notes
MD	Maintenance domain	MD is the administrative container that defines the scope, reach and boundary for CFM message handling. It is typically the area of ownership and management responsibility. MD levels are in the range from 0 to 7, where the larger the domain, the larger the MD level assigned.
MA	Maintenance association	MA is the construct where the different management entities such as MEPs are contained. An MA is created within an MD. There is also an administrative context where a linkage is made between the domain and the service using the MA bridging-identifier configuration option.
MEG	Maintenance entity group	Typically, an MEG represents one service and consists of a group of MEPs. Only one MEG can be associated with a service, but one service can be associated with multiple MEGs. MDs and MEGs are distributed to NEs using policy distribution.
MEP	Maintenance endpoint	MEPs are the entities at the edge of a CFM MD and define the boundary for the domain. MEPs are responsible for initiating, processing, and terminating CFM messages. Each MEP with the same MD and MA represents endpoints for a single service.

CFM DMM

For CFM Delay Measurement Message (DMM) tests, calculations are made to report on three criteria: frame delay, frame delay range, and interframe delay variation. DMM test frames are issued at regular intervals from a source MEP. Delay measurement information for the forward, backward, and round trip paths is determined from the DMR frames received from the destination MEP.

CFM linktrace

CFM linktrace messages that contain a target unicast MAC address are sent to multicast destination MAC addresses. Each MIP at the same MD level replies with a linktrace response. Messages are forwarded to the next hop until they reach the destination MAC address.

Results of each hop are displayed in the NSP.

Note: Round trip time, TTL, and probe details are not displayed in the NSP for linktrace tests.

CFM LMM

The CFM Loss Measurement Message (LMM) single-ended session test is a method of exchanging transmit and receive counters between peer MEPs to determine the exact loss on a point-to-point Ethernet virtual circuit.

The following validations are performed:

The LMM test suite tests can only be created or executed for MEG subgroups with exactly two MEPs.
The LMM test suite tests can only be executed if the source and target MEPs are not already the source or target MEPs (respectively) of a currently running LMM test.

CFM loopback

CFM loopback messages are sent to a unicast destination MAC address. The MEP at the destination responds to the loopback message with a loopback reply. An MEP or MIP can reply to a loopback message if the destination MAC address matches the MAC address of the MEP or MIP. CFM loopback tests verify connectivity to a specific MEP or MIP.

You can also perform multicast loopbacks by providing a multicast address (class 1 multicast destination) that aligns with the level that the originating MEP is configured on. Only one multicast test can be run at a time per NE, and results from the previous test are deleted when a new test is started. The stored values include the responding MEP MAC address, the sequence number, and a locally-assigned Rx index (allowing you to detect out-of-order responses).

CFM SLM

The CFM Synthetic Loss Measurement (SLM) session test is an extension of the Y.1731 standard that provides a method of exchanging transmit and receive counters to determine frame loss between a MEP and the destination MAC address or remote MEP ID of another node in the network. This test is used to verify MEP-MEP connectivity in the network and can be used to approximate the frame loss of actual data traffic. CFM SLM session tests measure frame loss using synthetic frames rather than data traffic. Frame loss is measured by calculating the difference between the number of synthetic frames that are sent and received.

TWAMP Light

The PM session testing framework can also be used in the IP domain to perform TWAMP IP level monitoring over IPv4 and IPv6 addresses.

TWAMP is a delay/loss measurement protocol that uses both the TCP connection service and the UDP session service. TWAMP Light tests target Layer 3 interfaces, providing an option to monitor IP SLA performance as related to KPIs.

TWAMP Light tests can operate on a base router or on routing instances belonging to L3VPNs. The target, or destination entity, requires configuration of a TWAMP Light reflector with a prefix associated with the TWAMP Light test source IP address and a specified UDP listening port in the range specified for the NE type. For example, the 7750 SR TWAMP Light reflector destination port range is 864, 64364-64373. A target node requires a configured reflector for the base router instance or for each of the tested L3VPN-based virtual routing instances.

TWAMP Light tests require a UDP source port in range undefined or configured in the NE range and a UDP destination port that matches the target device reflector UDP listening port.

Twamp reflectors, Twamp servers, and streaming templates cannot be configured in NSP. They can be discovered from the router configuration or configured using RESTCONF; see the OAM Tests tutorial on the Network Developer Portal for RESTCONF information.

See the Data Collection and Analysis Management, Config Objects view for the list of configured Twamp reflectors.

TWAMP Light test types

You can configure a TWAMP Light test to record delay, loss, or delay and loss statistics. Delay tests provide streaming results, accounting-session, and accounting-bin type results; loss tests provide accounting-loss-session type results. Streaming results require configuration of a streaming delay template. The streaming template defines the frequency at which real-time streaming results are received.

Accounting type results require configuration of an accounting policy, a file policy, and associated TWAMP Light measurement interval configuration.