ITU-T Y.1731 Performance Monitoring In a Service Provider Network
Available Languages
Table Of Contents
ITU-T Y.1731 Performance Monitoring In a Service Provider Network
Prerequisites for ITU-T Y.1731 Performance Monitoring In a Service Provider Network
Restrictions for ITU-T Y.1731 Performance Monitoring In a Service Provider Network
Information About ITU-T Y.1731 Performance Monitoring In a Service Provider Network
Frame Loss Measurement (ETH-LM) in a Point-to-Point Connection
Frame Delay and Frame-Delay Variation
Benefits of ITU-T Y.1731 Performance Monitoring
How to Configure ITU-T Y.1731 Performance Monitoring In a Service Provider Network
Configuration Examples for Configuring ITU-T Y.1731 Performance Monitoring Functions
Feature Information for ITU-T Y.1731 Performance Monitoring In a Service Provider Network
ITU-T Y.1731 Performance Monitoring In a Service Provider Network
First Published: March 30, 2011Last Updated: March 30, 2011ITU-T Y.1731 performance monitoring provides standards-based Ethernet performance monitoring that encompasses the measurement of Ethernet frame delay, frame delay variation, and frame loss 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.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for ITU-T Y.1731 Performance Monitoring In a Service Provider Network" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for ITU-T Y.1731 Performance Monitoring In a Service Provider Network
•
•
•
•
•
Prerequisites for ITU-T Y.1731 Performance Monitoring In a Service Provider Network
•
Restrictions for ITU-T Y.1731 Performance Monitoring In a Service Provider Network
•
•
•
•
Information About ITU-T Y.1731 Performance Monitoring In a Service Provider Network
The operations, administration, and maintenance (OAM) function for Y.1731 performance monitoring measures the following performance parameters:
•
Frame Loss Ratio
The Frame Loss Ratio (FLR) parameter is used to collect the FLR value. FLR is expressed as a percentage of the number of undelivered service frames divided by the total number of service frames during a specified time interval. The number of undelivered service frames is the difference between the number of service frames arriving at the ingress Ethernet flow point (EFP) and the number of service frames delivered at the egress EFP in a point-to-point connection.
Frame Loss Measurement (ETH-LM) in a Point-to-Point Connection
The Frame Loss Measurement (ETH-LM) parameter is used to collect counter values for ingress and egress service frames. The counters maintain the number of transmitted and received data frames between a pair of maintenance endpoints (MEPs).
Near-end frame loss is associated with ingress data frames, and far-end frame loss is associated with egress data frames. Both near-end and far-end frame loss measurements contribute to both near-end and far-end severely errored seconds, which together contribute to unavailable time.
Note
ETH-LM is performed when peer MEPs send and receive frames with ETH-LM information. Because a bidirectional service is defined as unavailable if either of the two directions is declared not viable, ETH-LM must facilitate near-end and far-end frame loss measurements by each MEP.
A MEP must maintain the following two local counters for each peer MEP and for each priority class. An in-profile data frame is an OAM frame from a maintenance entity group (MEG) level higher than the MEP.
•
•
TxFC1and RxFC1 count only in-profile data frames, which pass through the MEP in a manner similar to data frames. In the case of single-ended ETH-LM, only automatic protection switching (ETH-APS) and continuity check (ETH-CC) OAM packets at a level higher than the MEP are required to be counted. In the case of dual-ended ETH-LM, only ETH-APS OAM packets at a level higher than the MEP are required to be counted. Dual-ended ETH-LM is not supported in Cisco IOS Release 5.1(2)S.
To support ETH-LM, MEPs require the following configuration information:
•
•
An ETH-LM transmission period should be established so that the frame, octet, or both counters whose values are carried in the ETH-LM information do not wrap around to the same value, even if one or more ETH-LM frames are lost. Table 1 shows the frame counter wrapping periods.
•
Single-Ended ETH-LM
Single-ended ETH-LM is used for on-demand OAM. In this case, to carry out loss measurements a MEP sends frames with ETH-LM request information to its peer MEP and receives frames with ETH-LM reply information. The frames with request information are called loss measurement messages (LMMs), and the frames with the reply information are called loss measurement replies (LMRs). Both LMMs and LMRs have formats different from a continuity check message (CCM) frame.
When a valid LMM frame is received by a MEP, an LMR frame is generated and transmitted to the requesting MEP. An LMM frame with a valid MEG level and a destination MAC address equal to the receiving MEP's MAC address is considered to be a valid LMM frame. When a MEP receives an LMR frame, that MEP makes near-end and far-end loss measurements.
Availability
An SLA can be made for the number of frames lost (for example, no more than two in-band frames may be lost in any one second) or in terms of FLR (for example, no more than 30 percent of the transmitted frames may be lost in any one second). Frames lost can only be measured in a point-to-point service and accurate measurement requires hardware assistance that is beyond what is practical to implement. The ITU Y.1731 Performance Monitoring feature uses FLR.
For a point-to-point Ethernet virtual connection (EVC), the ITU states that a period of unavailable time begins at the onset of 10 consecutive measurement periods, in each of which more than 30 percent of the frames are lost. During the unavailable time period, the Ethernet network is in an unavailable state. A new period of available time begins at the onset of 10 consecutive measurement periods, in each of which fewer than 30 percent of the frames are lost.
Note
When calculating monthly or yearly averages, the amount of time to detect availability is also the minimum amount of time that an EVC can be down. Figure 1 is an example of determining unavailability.
Figure 1
Example of Determining Unavailability
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 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.
A MEP requires the following specific configuration information to support ETH-DM:
•
•
•
•
•
•
A MEP transmits frames with ETH-DM information using the TxTimeStampf information element. TxTimeStampf is the timestamp 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 valued copied from the ETH-DM request information.
Two-way frame delay is calculated as frame delay = RxTimeb - TxTimestampf, 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 timestamps in the ETH-DM reply information:
•
•
Note
A MIP is transparent to the frames with ETH-DM information; therefore a MIP does not require information to support the ETH-DM function.
Figure 2 shows a functional overview of a typical network in which Y.1731 performance monitoring is used.
Figure 2
Functional Overview of Y.1731 Performance Monitoring in a Network
Benefits of ITU-T Y.1731 Performance Monitoring
Combined with IEEE-compliant 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
To configure and display performance monitoring parameters, see Configuring Metro Ethernet 3.0 (ITU-T Y.1731).
Four new commands were introduced with the Y.1731 Performance Monitoring feature in Cisco IOS Release 15.1(2)S: debug ethernet cfm pm, ethernet cfm distribution enable, monitor loss counters, and show ethernet cfm pm.
The command [no] ethernet cfm distribution enable was introduced to manage the CFM distribution function. This command is disabled by default. When the ethernet cfm distribution enable command is issued, all MEPs and CFM information is transmitted via Internet Protocol Communications (IPC) to the ES+ line card. When the no ethernet cfm distribution enable command is issued, all MEPs and CFM information on the ES+ line card are removed. The ethernet cfm distribution enable command should be configured only when CFM distribution needs to be managed.
Caution
For more information about the [no] ethernet cfm distribution enable command and other 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
For Y.1731 performance monitoring configuration examples, see Configuring Metro Ethernet 3.0 (ITU-T Y.1731).
Additional References
Related Documents
IEEE CFM
Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network
Using OAM
IEEE CFM and Y.1731 commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Debug commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Standards
IEEE 802.1ag
802.1ag - Connectivity Fault Management
ITU-T Y.1731
ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks
MEF 17
Service OAM Requirements & Framework - Phase 1
MIBs
None
To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
Technical Assistance
Feature Information for ITU-T Y.1731 Performance Monitoring In a Service Provider Network
Table 2 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2011 Cisco Systems, Inc. All rights reserved.
Feedback