Cisco 7600 Series Router Software Configuration Guide Cisco IOS Release 15S
Y.1731 Performance Monitoring

Table Of Contents

Y.1731 Performance Monitoring

Understanding Y.1731 Performance Monitoring

Connectivity

Frame Delay and Frame Delay Variation

Frame Loss Ratio and Availability

Supported Interfaces

Guidelines and Restrictions for LMM over Port-Channel

Restrictions and Usage Guidelines

Configuring Y.1731 PM


Y.1731 Performance Monitoring


This chapter describes how to configure the Y.1731 Performance Monitoring in Cisco IOS Software Release 15.1(2)S.

This chapter includes the following sections:

Understanding Y.1731 Performance Monitoring

Configuring Y.1731 PM

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 7600 platform should be able to send, receive and process PM frames in intervals of 10ms (100 frames per second) with the maximum recommended transmission period being 100ms (10 frames 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 73-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 73-1 A Point-to-Point Metro Ethernet Deployment with Typical Maintenance Entities and Maintenance Points

Following are the performance monitoring parameters:

Connectivity

Frame Delay and Frame Delay Variation

Frame Loss Ratio and Availability

Connectivity

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: http://www.cisco.com/en/US/docs/routers/7600/install_config/ES40_config_guide/es40_chap4.html#wp1608025

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:
Each MEP transmits frames with one-way ETH-DM information to its peer MEP in a point-to-point ME to facilitate one-way frame delay and/or one-way frame delay variation measurements at the peer MEP. One way frame delay requires clock to be synchronized at both ends while frame delay variation doesn't require clock synchronization. It is measured using a single delay measurement (1DM) or Delay Measurement Message (DMM) and Delay Measurement Reply (DMR) frame combination.

Two-way ETH-DM:
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.


Note On a Cisco 7600 router, clock synchronization is achieved using a 2-port gigabit synchronous ethernet SPA. On an ES+ line card, the Real Time Clock (RTC) is synchronized to the 2-port gigabit synchronous ethernet SPA time source using Precision Time Protocol (PTP) as the time source protocol. If the time source selected is PTP, all the Y.1731 PM delay packets should have the 1588V2 timestamps.

For a 7600 router that does not have 2-Port Gigabit Synchronous Ethernet SPA, delay measurement is done by using the timestamps with Network Time Protocol (NTP) as the time source protocol. This is applicable only to One-way delay measurements.
To initiate Time of Day (ToD) synchronization on a line card, use the platform time-source command in global configuration mode. For more information on the platform time source command see: http://www.cisco.com/en/US/docs/ios/interface/command/reference/ir_o1.html

Frame Loss Ratio and Availability

Ethernet frame Loss Measurement (ETH-LM) is used to collect counter values applicable for ingress and egress service frames where the counters maintain a count of transmitted and received data frames between a pair of MEPs.

ETH-LM transmits frames with ETH-LM information to a peer MEP and similarly receives frames with ETH-LM information from the peer MEP. Each MEP performs frame loss measurements which contribute to unavailable time. A near-end frame loss refers to frame loss associated with ingress data frames. Far-end frame loss refers to frame loss associated with egress data frames. Both near-end and far-end frame loss measurements contribute to near-end severely errored seconds and far end severely errored seconds which together contribute to unavailable time.

These are the two methods of frame loss measurement, defined by the ITU-T Y.1731 standard:

Single-ended ETH-LM: Each MEP transmits frames with the ETH-LM request information to its peer MEP and receives frames with ETH-LM reply information from its peer MEP to carry out loss measurements.

Dual-ended ETH-LM: Each MEP transmits periodic dual-ended frames with ETH-LM information to its peer MEP in a point-to-point ME and facilitates frame loss measurements at the peer MEP. As of now, the Cisco 7600 router does not support Dual-ended ETH-LM.

Y.1731 PM Synthetic Loss Measurement

Synthetic Loss Measurement (SLM) is an extension of the existing Y.1731 PM feature, and makes use of an additional functionality defined in the latest version of the ITU-T Y.1731 (2011) standard. SLM measures frame loss using synthetic frames, rather than data traffic. Frame loss is measured by calculating the difference between the number of synthetic frames that are sent and received.

Single-ended ETH-SLM

Single-ended ETH-SLM carries out synthetic loss measurements applicable to both point-to-point ETH connection or multipoint ETH connectivity. The MEP sends frames with the ETH-SLM request information to its peer MEPs and receives frames with ETH-SLM reply information from its peer MEPs to measure synthetic loss.

Supported Interfaces

Y.1731 PM supports these interfaces:

LMM, DMM and 1DM support on EVC BD OFM

LMM, DMM and 1DM support on PC EVC BD OFM

LMM, DMM and 1DM support on EVC Xconnect OFM

LMM, DMM and 1DM support on PC EVC Xconnect OFM

LMM, DMM and 1DM support on EVC Xconnect IFM

LMM, DMM and 1DM support on PC EVC Xconnect IFM

LMM, DMM and 1DM support on Subinterfaces (routed port)

LMM, DMM and 1DM support on PC Subinterfaces (routed port)


Note Release 15.4(1)S onwards, LMM over Port-Channel supports member links on different network processors (NP) and different line cards (LC). This support is available only if fast-switchover is also configured.


Guidelines and Restrictions for LMM over Port-Channel

LMM over Port-Channel is supported only if it has two member links in the active-standby mode.

The member link switchover invalidates the IP SLA session. The session remains invalid till the end of the SLA aggregate interval. The session will resume only at the start of the next aggregate interval.


Note PM is supported in the EVC and CFM configurations mentioned above, with both Dot1q and QinQ encapsulations available on the EVC.


Y.1731 PM SLM supports these interfaces:

SLM and SLR packet-type support on EVC BD OFM

SLM and SLR packet-type support on EVC BD IFM

SLM and SLR packet-type support on PC EVC BD OFM

SLM and SLR packet-type support on PC EVC BD IFM

SLM and SLR packet-type support on EVC cross-connect OFM

SLM and SLR packet-type support on EVC cross-connect IFM

SLM and SLR packet-type support on PC EVC cross-connect IFM

SLM and SLR packet-type support on PC EVC cross-connect OFM

SLM and SLR packet-type support on subinterfaces (routed port)

SLM and SLR packet-type support on PC subinterfaces (routed port)

Restrictions and Usage Guidelines

Follow these restrictions and usage guidelines when you configure Y.1731 PM on an ES+ line card:

If the route processor CPU is busy with other processes and if software forwarding is used, the performance monitoring statistics are not accurate.

Y.1731 PM measurement only works for a point to point network topology.

Y.1731 PM is not SSO compliant. After switchover all sessions data is cleared and IPSLA restart is required.

When monitor loss counter CLI is configured under MEP, Y1731 SLM does not work properly. It can cause line card reload.

In case of one way session or two way session, when one way statistics are required, PTP needs to be synchronized between peers and stable. You should delay starting of sessions in such situations.

On Cisco 7600 series router, only ES+Line Card is supported in non-switchport mode. PM is not supported on Port MEPs.

PM is not supported on these interfaces:

mLACP interfaces

EVC BD IFM

Swicthport OFM and IFM

Port MEPs

PM is not supported on VPLS configuration.

PM is not supported on Qinq subinterfaces, as CFM is not supported on these interfaces.

PM does not support SNMP, although CLI and system-logging is supported.

Frame Throughput measurements are not supported.

These are the restrictions for PM support on Port-channel:

Adding or deleting a member link renders the session invalid.

Loss measurement on port-channel interfaces is supported only if all physical interfaces of the port-channel are present on a single NPU. This restriction cannot be applied for delay measurements.

All the member links have to be ES+ ports.

PM is not supported on manual PC EVC Load balancing configuration (UNI LAG).

CFM Y.1731 packets work with a maximum of two VLAN tags. Expected behavior is not observed with more VLAN tags. CFM Y.1731 packets does not work with untagged cases.

Configuring Y.1731 PM

For information on Y.1731 PM configurations, see: http://www.cisco.com/en/US/docs/routers/7600/install_config/ES40_config_guide/es40_chap4.html#wp1708139