Understanding Y.1731 Performance Monitoring
When service providers sell connectivity services to a subscriber, a Service Level Agreement (SLA) is reached between the buyer and seller of the service. The SLA defines the attributes offered by a provider and serves as a legal obligation on the service provider. As the level of performance required by subscribers increases, service providers need to monitor the performance parameters being offered. In order to capture the needs of the service providers, organizations have defined various standards such as IEEE 802.1ag and ITU-T Y.1731 that define the methods and frame formats used to measure performance parameters.
Y.1731 Performance Monitoring (PM) provides a standard ethernet PM function that includes measurement of ethernet frame delay, frame delay variation, frame loss, and frame throughput measurements specified by the ITU-T Y-1731 standard and interpreted by the Metro Ethernet Forum (MEF) standards group. As per recommendations, the ME 3600X and ME3800X switches should be able to send, receive and process PM frames in intervals of 1000ms (1 frame per second) with the maximum recommended transmission period being 1000ms (1 frame per second) for any given service.
To measure SLA parameters such as frame delay or frame delay variation, a small number of synthetic frames are transmitted along with the service to the end point of the maintenance region, where the Maintenance End Point (MEP) responds to the synthetic frame. For a function such as connectivity fault management, the messages are sent less frequently, while performance monitoring frames are sent more frequently.
Figure 44-1 Figure 44-1 illustrates Maintenance Entities (ME) and Maintenance End Points (MEP) typically involved in a point-to-point metro ethernet deployment for the Y.1731 standard.
Figure 44-1 A Point-to-Point Metro Ethernet Deployment with Typical Maintenance Entities and Maintenance Points
Following are the performance monitoring parameters:
Frame Delay and Frame Delay Variation
Frame Loss Ratio and Availability
The first step to performance monitoring is verifying the connectivity. Continuity Check Messages (CCM) are best suited for connectivity verification, but is optimized for fault recovery operation. It is usually not accepted as a component of an SLA due to the timescale difference between SLA and Fault recovery. Hence, Connectivity Fault Management (CFM) and Continuity Check Database (CCDB) are used to verify connectivity. For more information on CFM see: Configuring Ethernet OAM, CFM, and E-LMI
Frame Delay and Frame Delay Variation
Ethernet frame Delay Measurement (ETH-DM) is used for on-demand ethernet Operations, Administration & Maintenance (OAM) to measure frame delay and frame delay variation.
Ethernet frame delay and frame delay variation are measured by sending periodic frames with ETH-DM information to the peer MEP and receiving frames with ETH-DM information from the peer MEP. During the interval, each MEP measures the frame delay and frame delay variation.
Ethernet frame delay measurement also collects useful information, such as worst and best case delays, average delay, and average delay variation. Ethernet frame delay measurement supports hardware-based timestamping in the ingress direction. It provides a runtime display of delay statistics during a two-way delay measurement. Ethernet frame delay measurement records the last 100 samples collected per remote Maintenance End Point (MEP) or per CFM session.
These are the two methods of delay measurement, as defined by the ITU-T Y.1731 standard, One-way ETH-DM and Two-way ETH-DM. However only Two-way ETH-DM is supported.
Each MEP transmits frames with ETH-DM request information to its peer MEP and receives frames with ETH-DM reply information from its peer MEP. Two way frame delay and frame delay variation is measured using DMM and DMR frame.
These are the pre-requisites for 1DM measurements:
– The clocks of the two concerned end-points must be synchronized accurately and precisely. This is achieved through IEEE 1588-2002.
– There is no auto-session create supported on the peer or the receiver. You need to configure an receive-only session.
– You must configure all the create sessions on the receiver's datapath. These are passive listener sessions.
Y.1731 PM supports these interfaces:
DMM support on EVC BD OFM
DMM support on PC EVC BD OFM
DMM support on EVC Xconnect OFM
DMM support on PC EVC Xconnect OFM
DMM support on EVC BD IFM
DMM support on PC EVC BD IFM
DMM support on EVC Xconnect IFM
DMM support on PC EVC Xconnect IFM
Note PM is supported in the EVC and CFM configurations mentioned above, with both Dot1q and QinQ encapsulations available on the EVC.
Restrictions and Usage Guidelines
Follow these restrictions and usage guidelines when you configure Y.1731 PM on an line card:
Y.1731 PM is not supported on these interfaces:
– Switchport Upward facing MEP and Downward facing MEP
– Port MEPs
Frame interval of 1000 ms is only supported
PM does not support SNMP, although CLI and system-logging is supported
Frame Throughput measurements are not supported
Clock synchronization is not mandatory for Two-way Delay Measurement
These are the restrictions for PM support on Port-channel:
Adding or deleting a member link renders the session invalid.
PM is not supported on manual PC EVC Load balancing configuration (UNI LAG).