How do OAM tests work?

CFM test types

CFM and Twamp-light session tests are supported.

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.

The PM session testing framework can also be used in the IP domain to perform TWAMP IP level monitoring, and runs over IPv4 and IPv6 addresses. TWAMP Light tests target Layer 3 interfaces, providing an option to monitor IP SLA performance as related to KPIs.

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 link trace 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 link trace 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 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. A MEP or a 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.

The telemetry types supported depends on the NE type. For SR OS NEs, cfm-slm-session-acc-stats telemetry is supported. For Wavence NEs, eth-cfm-slm-loss-session telemetry is supported.

Twamp-light

Twamp is a delay/loss measurement protocol that uses both the TCP connection service and the UDP session service.

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.