The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
ITU-T Y.1731 performance monitoring provides standard-based Ethernet performance monitoring that encompasses the measurement of Ethernet frame delay, frame-delay variation, and throughput as outlined in the ITU-T Y.1731 specification and interpreted by the Metro Ethernet Forum (MEF). Service providers offer service level agreements (SLAs) that describe the level of performance customers can expect for services. This document describes the Ethernet performance management aspect of SLAs.
IEEE-compliant connectivity fault management (CFM) must be configured and enabled for Y.1731 performance monitoring to function.
 Note |
Y1731 is supported over Port Channel interfaces. |
The frame-delay measurement message (DMM) with CFM over cross-connect on the router works only if the control-word command is enabled.
When the core network has multiple paths, the Tx and Rx, DMM/DMR packets can be sent and received on different ports. If the ports belong to a different interface module (IM), time stamping can be out of sync and in certain cases the Rx value can be lower than the Tx value. This value is displayed as 0 in the raw database output. As a workaround, configure Precision Time Protocol (PTP) between the two connectivity fault management (CFM) endpoint routers.
RSP3 module supports ASIC-based timestamping. When the sending and receiving ports of the Tx and Rx packets are on the same ASIC module, there is no dys-synchronization between the sending and receiving ports. However, if the sending and receiving ports are on different ASIC modules, the Precision Time Protocol (PTP) is to be configured between the two connectivity fault management (CFM) endpoint routers.
Y.1731 is supported with the rewrite command configuration on Ethernet Flow Points (EFPs) throughout the Layer 2 circuit. However, the configuration may be in such a way that the Y1731 PDUs may be transmitted untagged. This results in the other end of the Layer 2 circuit not being able to ascertain the CoS value which determines the SLA session to which the PDUs belong. Therefore, the rewrite command configuration is not supported when CoS value is configured with IP SLA or the Y.1731 profile.
Y.1731 performance monitoring is not supported in MEPs that are configured on TEFP on the RSP3 module.
Y.1731 performance monitoring is not supported in MEPs that are configured on ports.
CFM and Y.1731 performance monitoring on a port-channel is not supported on the RSP3 mdoule, in Cisco IOS XE Release 3.18SP and earlier.
LMM is not supported on the RSP3 module.
Note |
In ITU-T Y1731, 1DM measurement should mandate only PTP to have clock sync between sender & receiver. |
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:
MEG level—MEG level at which the MEP exists
Priority
Drop eligibility—marked drop ineligible
Transmission rate
Total interval of ETH-DM
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 formula frame delay = RxTimef – TxTimeStampf.
One-way frame-delay 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) frame combination.
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 reply information:
RxTimeStampf—Time stamp of the time at which the frame with ETH-DM request information was received.
TxTimeStampb—Time stamp of the time at which the transmitting frame with ETH-DM reply information was sent.
The timestamping happens at the hardware level for DMM operations.
Note |
The frame-loss, frame-delay, and frame-delay variation measurement processes are terminated 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.
Combined with IEEE-compliant connectivity fault management (CFM), Y.1731 performance monitoring provides a comprehensive fault management and performance monitoring solution for service providers. This comprehensive solution in turn lessens service providers’ operating expenses, improves their service-level agreements (SLAs), and simplifies their operations.
The following new commands were introduced that can be used to configure and display performance monitoring parameters: debug ethernet cfm pm , monitor loss counters , and show ethernet cfm pm .
For more information about CFM and Y.1731 performance monitoring commands, see the Cisco IOS Carrier Ethernet Command Reference. For more information about debug commands, see the Cisco IOS Debug Command Reference.
For Y.1731 performance monitoring configuration examples, see Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations. For information on Y.1731 On-Demand and Concurrent Operations see, IPSLA Y1731 On-Demand and Concurrent Operations.
Feedback