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 in a Service Provider Network
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.
Prerequisites for ITU-T Y.1731 Performance Monitoring in a Service Provider Network
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.
Restrictions for
ITU-T Y.1731 Performance Monitoring in a Service Provider Network
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 rewritecommand 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.
CFM and Y.1731performance monitoring on a port-channel is supported on the RSP3 module starting Cisco IOS XE Everest 16.5.1. The supported scale value is 500 sessions.
LMM is not supported on the RSP3 module.
Y.1731 DMM is not supported on the RSP3 platform, when there are two VLAN tags, two or more MPLS tag with control word enabled
on the system.
Note
In ITU-T Y1731,
1DM measurement should mandate only PTP to have clock sync between sender &
receiver.
Information About ITU-T Y.1731 Performance Monitoring in a Service Provider Network
Frame Delay and Frame-Delay
Variation
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.
Benefits of ITU-T Y.1731 Performance Monitoring
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.
How to Configure ITU-T Y.1731 Performance Monitoring in a Service Provider Network
Configuring Performance
Monitoring Parameters
The following new
commands were introduced that can be used to configure and display performance
monitoring parameters:
debugethernetcfmpm,
monitorlosscounters, and
showethernetcfmpm.
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.
Configuration Examples for Configuring ITU-T Y.1731 Performance Monitoring Functions
Example: Configuring
Performance Monitoring
For Y.1731 performance monitoring configuration examples, see Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations. For information about Y.1731 On-Demand and Concurrent Operations, see Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations.
Application of QoS Policies on ITU-T Y.1731 Egress Packets
Table 1. Feature History
Feature Name
Release Information
Feature Description
Application of QoS Policies on ITU-T Y.1731 Egress Packets
Cisco IOS XE Cupertino 17.9.1
You can now apply QoS policies on Y.1731 egress packets. Operations, Administration, and Maintenance (OAM) functions and mechanisms
for Ethernet-based networks are defined in ITU-T Y.1731. With this implementation, you can prioritize OAM traffic; for example,
prioritizing operational information used to detect faults and determining network performance.
The number of Y.1731 egress packets that are dropped, due to bandwidth limitation, must be reflected accurately. To facilitate
the application of QoS on Y.1731 egress packets, the following requirements are implemented:
Note
We recommend that you maintain sufficient free QoS labels to enable QoS for Y.1731 egress packets.
Y.1731 performance management probe packets are subject to QoS on the measurement nodes because they have appropriate packet
type of service (ToS) marking to take the same path as regular data do through the transit nodes. Packets are processed identically
in the transit path.
Y.1731 packet must bypass ingress QoS at user-network interface (UNI) and hit EQoS on the network-network interface (NNI)
of endpoints.
Ensure that Y.1731 functionalities, such as delay measurement and frame-delay measurement message (DMM) packets, are considered
as transit traffic, because these packets measure the delay of green packets in the network.
For MPLS, the CoS-EXP mapping is preserved for CPU-injected Y.1731 traffic.
Restrictions for the Application of QoS on Y.1731 Egress Packets
In case of data traffic not marked with MPLS EXP at the imposition, all packets fall under the class-default policy-map at the egress. In such cases, if the Y.1731 sessions also have CoS 0 configured in them, then the Y.1731 packets are likely to get discarded, subject to the bandwidth availability.
It is supported only in L2VPN (Xconnect/VPLS) services.
It is not supported for EVC BD services.
It is not supported with CFM Down MEP sessions.
Enabling QoS on ITU-T Y.1731 Egress Packets
Follow the steps below to apply egress QoS on ITU-T Y.1731 egress packets:
Execute the platform qos-feature y1731-qos enable command to enable QoS for Y.1731 egress packets.
Note
Use the no form of the command to disable QoS for Y.1731 egress packets.
Execute the write memory command to save the running configuration as the startup configuration.
Reload the system for the configuration to take effect.
Example
Router#show run | sec y1731-qos
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#platform qos-feature y1731-qos en
Router(config)#end
Router#show run | sec y1731-qos
platform qos-feature y1731-qos enable
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#no platform qos-feature y1731-qos enable
Router(config)#end
Configuration Example
This example shows the configuration of Y.1731 Dela Measurement Messages (DMM)/1DM frames and Synthetic Loss Measurement (SLM)/Loss
Measurement Management (LMM):
ip sla 1
ethernet y1731 delay DMM domain d1 evc evc10 mpid 1002 cos 4 source mpid 1001
frame size 1000
frame interval 10
ip sla schedule 1 life forever start-time now
ip sla 2
ethernet y1731 delay 1DM domain d1 evc evc10 mpid 1002 cos 0 source mpid 1001
frame size 1000
frame interval 10
ip sla schedule 2 life forever start-time now
ip sla 3
ethernet y1731 loss SLM domain d1 evc evc10 mpid 1002 cos 6 source mpid 1001
frame size 1000
frame interval 10
ip sla schedule 3 life forever start-time now
ip sla 4
ethernet y1731 loss LMM domain d1 evc evc10 mpid 1002 cos 8 source mpid 1001
frame interval 10
ip sla schedule 4 life forever start-time now