The Frame Delay
parameter can be used for on-demand OAM measurements of frame delay and
frame-delay variation. When a maintenance end point (MEP) is enabled to
generate frames with frame-delay measurement (ETH-DM) information, it
periodically sends frames with ETH-DM information to its peer MEP in the same
maintenance entity. Peer MEPs perform frame-delay and frame-delay variation
measurements through this periodic exchange during the diagnostic interval.
An MEP requires the
following specific configuration information to support ETH-DM:
level at which the MEP exists
Drop eligibility—marked drop ineligible
Total interval of
MEF10 frame-delay variation algorithm
A MEP transmits
frames with ETH-DM information using the TxTimeStampf information element.
TxTimeStampf is the time stamp for when the ETH-DM frame was sent. A receiving
MEP can compare the TxTimeStampf value with the RxTimef value, which is the
time the ETH-DM frame was received, and calculate one-way delay using the
frame delay =
RxTimef – TxTimeStampf.
measurement (1DM) requires that clocks at both the transmitting MEP and the
receiving MEPs are synchronized. Measuring frame-delay variation does not
require clock synchronization and the variation can be measured using 1DM or a
frame-delay measurement message (DMM) and a frame-delay measurement reply (DMR)
If it is not
practical to have clocks synchronized, only two-way frame-delay measurements
can be made. In this case, the MEP transmits a frame containing ETH-DM request
information and the TxTimeStampf element, and the receiving MEP responds with a
frame containing ETH-DM reply information and the TxTimeStampf value copied
from the ETH-DM request information.
Two-way frame delay is calculated as (RxTimeb–TxTimeStampf)–(TxTimeStampb–RxTimeStampf), where RxTimeb is the time that the frame with ETH-DM reply information was received. Two-way frame delay and variation can be measured using only DMM and DMR frames.
To allow more precise
two-way frame-delay measurement, the MEP replying to a frame with ETH-DM
request information can also include two additional time stamps in the ETH-DM
stamp of the time at which the frame with ETH-DM request information was
stamp of the time at which the transmitting frame with ETH-DM reply information
The timestamping happens at the hardware level for DMM operations.
The frame-loss, frame-delay, and frame-delay variation measurement processes are aborted when faults related to continuity and availability occur or when known network topology changes occur.
An MIP is transparent
to the frames with ETH-DM information; therefore, an MIP does not require
information to support the ETH-DM function.
The figure below
shows a functional overview of a typical network in which Y.1731 performance
monitoring is used.
Figure 1. Y.1731