Synthetic loss measurement (SLM) is part of the ITU-T Y.1731 standard. It can be used to periodically measure Frame Loss and Forward Loss Ratio (FLR) between a pair of point to point MEPs. Measurements are made between two MEPs belonging to the same domain and MA.
Synthetic loss measurement is a mechanism to measure frame loss using synthetic frames, rather than data traffic. A number of synthetic frames are sent and received, and the number of those that are lost is hence calculated to measure the loss.
Note
A MIP is transparent to the frames with ETH-SLM information and therefore does not require any information to support the ETH-SLM functionality.In a Two-Way ETH-SLM, Initiator (the source MEP) sends burst of Synthetic Loss Message (SLM) frames to Responder (the Remote MEP) and in turn receives Synthetic Loss Reply (SLR) frames to carry out synthetic loss measurements.
A MEP transmits burst of SLM frames once for every Tx-interval time period. Whenever a valid SLM frame is received by a MEP, an SLR frame is generated and transmitted to the initiating MEP. With the information contained in SLR frames, a MEP determines frame loss for given measurement periods.
For each MA where Two-Way ETH-SLM is configured, an MEP maintains two local counters for each peer MEP for each CoS instance which plays a role in calculating Loss Measurement.
TxFC1: Counter for synthetic frames transmitted towards the peer MEP. A source MEP increments this counter with transmission of SLM frames while a responder MEP increments it with transmission of SLR frames.
RxFC1: Counter for synthetic frames received from the peer MEP. A source MEP increments this counter with reception of SLR frames while a responder MEP increments it with reception of SLM frames.
A MEP uses the following values to determine near-end and far-end frame loss in the measurement period:
Frame lossfar-end = | TxFCf[tc] – TxFCf[tp] | – | TxFCb[tc] – TxFCb[tp] |
Frame lossnear-end = | TxFCb[tc] – TxFCb[tp] | – | RxFCl[tc] – RxFCl[tp] |
The following points applies to On-demand SLM.
The ETH-DM is used for on-demand OAM to measure frame delay and frame delay variation.
Frame delay and frame delay variation measurements are performed by sending frames with ETH-DM information to the peer MEP and receiving frames with ETH-DM information during the diagnostic interval. Each MEP performs the frame delay and frame delay variation measurement.
For the MEP to support ETH-DM, you must configure the following.
In a Two-way ETH-DM, an Initiator or a Source MEP sends frames with ETH-DM request information (DMM) to the Responder or a Remote MEP and in turn receives frames with ETH-DM reply information (DMR) to carry out two-way frame delay and two-way frame delay variation measurements.
When delay measurement is issued, a MEP transmits DMM frames with the 'TxTimeStampf' value.
When a valid DMM frame is received by a MEP, a DMR frame is generated and transmitted to the requesting MEP. A DMM frame with a valid domain level and a destination MAC address equal to the receiving MEP's MAC address is considered as a valid DMM frame. There are two additional timestamps which are used in the DMR frame to take into account the processing time at the remote MEP: 'RxTimeStampf' (Timestamp at the time of receiving the DMM frame) and 'TxTimeStampb' (Timestamp at the time of transmitting the DMR frame).
After receiving a DMR frame, a MEP tags the incoming frame with another timestamp 'RxTimeStampb' and uses the following values to calculate two-way frame delay.
Frame Delay = (RxTimeStampb - TxTimeStampf) - (TxTimeStampb - RxTimeStampf)
The MEP can also make two-way frame delay variation measurements based on its capability to calculate the difference between two subsequent two-way frame delay measurements.
SLX-OS provides the default test profile, configurable test profile and configurable action profile that can be associated to a source and target MEP pair at the initiator or responder side which establishes a session. This facilitates the user to apply all the parameters which are configured within the profile at once for a measurement session instead of specifying each parameter through the command-line interface (CLI).
The following table provides information on the two important counters used for loss measurement.
| Initiator | Responder | |
|---|---|---|
| TxFC1 | SLM Tx count | SLR Tx count |
| RxFC1 | SLR Rx count | SLM Rx count |
| Parameter | Default value |
|---|---|
| Name | 2dm-default-profile |
| CoS | 7 |
| tx Interval | 1 second |
| Measurement Interval | 15 minutes |
| Threshold average | 4294967295 uSec |
| Threshold Max | 4294967295 uSec |
| Start Time | 00:05:00 (After) |
| Stop Time | 01:05:00 (After) |
| Number of packets | 10 |
| Timeout | 1 second |
| Parameter | Default Value |
|---|---|
| Name | 2slm-default-profile |
| CoS | 7 |
| tx Interval | 1 second |
| Measurement Interval | 15 minutes |
| Threshold Backward Average | 4294967295 milliPercent |
| Threshold Backward Max | 4294967295 milliPercent |
| Threshold Forward Average | 4294967295 milliPercent |
| Threshold Forward Max | 4294967295 milliPercent |
| Start Time | 00:05:00 (After) |
| Stop Time | 01:05:00 (After) |
| Number of packets | 10 |
| Timeout | 1 second |
The default test profile can be associated with an on-demand session or a scheduled (or periodic) session.
Note
Default profiles can neither be updated nor be deleted.Note
For a scheduled session associated with a default profile, the start time can be 5 minutes and the stop time can be 1 hr 5 minutes from the time a session is configured that is for a total duration of one hour with measurement interval of 15 minutes.Note
Note: The threshold values in the default profile are set to MAX value and hence this cannot trigger Syslogs, SNMP Traps or any action if configured in action profile for the threshold parameter.Note
Tx-interval, measurement interval and threshold are applicable for only initiator and not for responder.Note
Start time, stop time and Tx-interval parameter default values are not applicable for an on-demand session.Note
For Two-way ETH-SLM sessions, the noumber of packets specified are sent in a burst at once for On Demand sessions and for every Tx-interval for Scheduled sessions. The timeout is applicable for the entire burst of frames for On-demand sessions.For Two-way ETH-DM sessions, the packets are sent sequentially after every reply message received for On-demand for a total number of packets specified and for every Tx-interval for scheduled (or periodic) sessions. The timeout is applicable per packet only for On-demand sessions.
Note
The configured test profile determines the type of Y.1731 measurement feature and the CLI used for initiating the measurement session is generic for both ETH-DM and ETH-SLM.Note
If a profile is updated which is already associated to an active Two-way ETH-DM or Two-way ETH-SLM session, the current active session(s) will be implicitly stopped before the profile is updated. The updated profile would be applicable for the next scheduled (or periodic) session(s). However as an exception, if the stop time in the profile associated with an active session is updated to a later time than the current time, the session(s) will not be stopped and the new configured stop time in the profile will be applied immediately.For an on-demand active session, there will be no impact of such updating of the associated profile.
Action profile: You can configure an action profile with options to specify which action has to be taken when a configured event is encountered.
The configurable actions are as follows:
Note
One action profile can have multiple event-action associations contained in it. The threshold values in the default profile are set to MAX value and hence this cannot trigger Syslog or any action, if configured in action profile for the threshold parameter.Note
The threshold events configured in an action profile can be triggered during an on-demand or a scheduled (or periodic) Two-way ETH-DM or Two-way ETH-SLM sessions.