Chapter 1. Configuring IP SLAs UDP Jitter Operations

Information About the IP SLAs UDP Jitter Operation

Prerequisites for Configuring IP SLAs UDP Jitter Operations

Guidelines and Limitations for UDP Jitter Operations

Configuring CoPP for IP SLA Packets

Matching the Netstack Port Range

Configuring and Scheduling a UDP Jitter Operation on the Source Device

Configuring the IP SLAs Responder on the Destination Device

Configuring and Scheduling a Basic UDP Jitter Operation on the Source Device

Configuring and Scheduling a UDP Jitter Operation with Additional Characteristics

Configuration Example for a UDP Jitter Operation

Chapter 2. Configuring IP SLAs UDP Jitter Operations for VoIP

Guidelines and Limitations for IP SLAs UDP Jitter Operations for VoIP

Calculated Planning Impairment Factor

Mean Opinion Scores

Voice Performance Monitoring Using IP SLAs

Codec Simulation Within IP SLAs

IP SLAs ICPIF Value

IP SLAs MOS Value

Configuring and Scheduling an IP SLAs VoIP UDP Jitter Operation

Configuration Examples for IP SLAs VoIP UDP Operation

Configuration Examples for IP SLAs VoIP UDP Operation Statistics Output

Glossary

Preface

Audience

Document Conventions

Related Documentation for Cisco Nexus 9000 Series Switches

Documentation Feedback

Obtaining Documentation and Submitting a Service Request

Copyright Page

Chapter 1. Configuring IP SLAs UDP Jitter Operations

This chapter describes how to configure an IP Service Level Agreements (SLAs) UDP jitter operation to analyze round-trip delay, one-way delay, one-way jitter, one-way packet loss, and connectivity in networks that carry UDP traffic in IPv4 networks. This chapter also demonstrates how the data gathered using the UDP jitter operation can be displayed and analyzed using the Cisco software commands.

This chapter includes the following sections:

- Information About the IP SLAs UDP Jitter Operation

- Prerequisites for Configuring IP SLAs UDP Jitter Operations

- Guidelines and Limitations for UDP Jitter Operations

- Configuring and Scheduling a UDP Jitter Operation on the Source Device

- Configuration Example for a UDP Jitter Operation

Information About the IP SLAs UDP Jitter Operation

The IP SLAs UDP jitter operation can diagnose network suitability for real-time traffic applications such as voice over IP (VoIP), video over IP, or real-time conferencing.

Jitter means inter-packet delay variance. When multiple packets are sent consecutively from source to destination, for example, 10 ms apart, and if the network is behaving ideally, the destination should be receiving them 10 ms apart. But if there are delays in the network (such as queuing, arriving through alternate routes, and so on), the arrival delay between packets might be greater than or less than 10 ms. Using this example, a positive jitter value indicates that the packets arrived greater than 10 ms apart. If the packets arrive 12 ms apart, then positive jitter is 2 ms; if the packets arrive 8 ms apart, then negative jitter is 2 ms. For delay-sensitive networks such as VoIP, positive jitter values are undesirable, and a jitter value of 0 is ideal.

However, the IP SLAs UDP jitter operation does more than just monitor jitter. As the UDP jitter operation includes the data returned by the IP SLAs UDP operation, the UDP jitter operation can be used as a multipurpose data gathering operation. The packets that IP SLAs generate carry packet sending sequence, receiving sequence information, and sending and receiving time stamps from the source and the operational target. UDP jitter operations can measure the following:

- Per-direction jitter (source to destination and destination to source)

- Per-direction packet-loss

- Per-direction delay (one-way delay)

- Round-trip delay (average round-trip time)

As the paths for the sending and receiving of data may be different (asymmetric), the per-direction data allow you to more readily identify where congestion or other problems are occurring in the network.

The UDP jitter operation functions by generating synthetic (simulated) UDP traffic. The UDP jitter operation sends N UDP packets, each of size S, sent T milliseconds apart, from a source switch to a target switch, at a given frequency of F. By default, ten packet-frames (N), each with a payload size of 10 bytes (S), are generated every 10 ms (T), and the operation is repeated every 60 seconds (F). Each of these parameters are user-configurable as shown in the following table.

UDP Jitter Operation Parameters

UDP Jitter Operation Parameter

Default

Command

Number of packets (N)

10 packets

udp-jitter command, numpackets option

Payload size per packet (S)

32 bytes

request-data-size command

Time between packets, in milliseconds (T)

20 ms

udp-jitter command, interval option

Elapsed time before the operation repeats, in seconds (F)

60 seconds

frequency (IP SLA) command

Prerequisites for Configuring IP SLAs UDP Jitter Operations

The prerequisites for configuring IP SLAs UDP jitter operations are as follows:

- Time synchronization, such as that provided by NTP, is required between the source and the target device in order to provide accurate one-way delay (latency) measurements. Time synchronization is not required for the one-way jitter and packet loss measurements. If the time is not synchronized between the source and target devices, one-way jitter and packet loss data are returned, but values of “0” are returned for the one-way delay measurements provided by the UDP jitter operation.

- Before configuring any IP SLAs application, you can use the show ip sla application command to verify that the operation type is supported on your software image.

Guidelines and Limitations for UDP Jitter Operations

- Configuring CoPP for IP SLA Packets

- Matching the Netstack Port Range

Configuring CoPP for IP SLA Packets

When using IP SLA operations on a large scale, a specific CoPP configuration to allow the IP SLA packets to pass through might be needed. Since IP SLA uses user defined UDP ports, there is no way to allow all IP SLA packets to the control plane. However, you can specify each destination/source port that IP SLA can use.

For more information about the verified scalability of the number of IP SLA probes, see the Cisco Nexus 9000 Series NX-OS Verified Scalability Guide.

The following shows an example of a CoPP configuration that allows IP SLA packets to pass through. It assumes destination ports and source ports in the range of 6500-7000.

ip access-list copp-system-sla-allow
10 remark ### ALLOW SLA control packets from 1.1.1.0/24
20 permit udp 1.1.1.0/24 any eq 1967
30 remark ### ALLOW SLA data packets from 1.1.1.0/24 using ports 6500-7000
40 permit udp 1.1.1.0/24 any range 6500 7000
statistics per-entry
ip access-list copp-system-sla-deny
10 remark ### this is a catch-all to match any other traffic
20 permit ip any any
statistics  per-entry
class-map type control-plane match-any copp-system-class-management-allow
match access-group name copp-system-sla-allow
class-map type control-plane match-any copp-system-class-management-deny
match access-group name copp-system-sla-deny
policy-map type control-plane copp-system-policy
class copp-system-class-management-allow
set cos 7
police cir 4500 kbps bc 250 ms conform transmit violate drop
class copp-system-class-management-deny
police cir 4500 kbps bc 250 ms conform drop violate drop
control-plane
service-policy input copp-system-policy

Matching the Netstack Port Range

IP SLA only accepts ports within the local netstack port range. The source and destination ports used in the probe's configuration must match the supported netstack ports on the SLA sender and the SLA responder.

You can use the show sockets local-port-range command to view the port range on the sender/responder.

The following is an example of viewing the netstack port range:

switch# show sockets local-port-range

Kstack local port range (15001 - 22002)
Netstack local port range (22003 – 65535)

Configuring and Scheduling a UDP Jitter Operation on the Source Device

This section describes how to configure and schedule a UDP jitter operation.

- Configuring the IP SLAs Responder on the Destination Device

- Configuring and Scheduling a Basic UDP Jitter Operation on the Source Device

- Configuring and Scheduling a UDP Jitter Operation with Additional Characteristics

Configuring the IP SLAs Responder on the Destination Device

This section describes how to configure the responder on the destination device.

Note

A responder should not configure a permanent port for the same sender. If the responder configures the permanent port for the same sender, even if the packets are successfully sent (no timeout or packet loss issues), the jitter values are zero.

Procedure

Command or Action

Purpose

Step 1

enable

Example:

switch> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

switch# configure terminal

Enters global configuration mode.

Step 3

feature sla responder

Example:

switch(config)# feature sla responder

Enables the IP SLAs responder feature.

Step 4

Do one of the following:

- ip sla responder

Example: switch(config)# ip sla responder

- ip sla responder udp-echo ipaddress ip-address port port

Example: switch(config)# ip sla responder udp-echo
ipaddress 172.29.139.132 port 5000

-

- (Optional) Temporarily enables the responder functionality on a Cisco device in response to control messages from a source.

- (Optional) Required only if protocol control is disabled on a source. Permanently enables the responder functionality on the specified IP addresses and port.

Control is enabled by default.

Step 5

exit

Example:

switch(config)# exit

(Optional) Exits global configuration mode and returns to privileged EXEC mode.

Configuring and Scheduling a Basic UDP Jitter Operation on the Source Device

This section describes how to configure and schedule a basic UDP jitter operation on the source device.

Tip

- If the IP SLAs operation is not running and generating statistics, add the verify-data command to the configuration of the operation (while configuring in IP SLA configuration mode) to enable data verification. When enabled, each operation response is checked for corruption. Use the verify-data command with caution during normal operations because it generates unnecessary overhead.

- Use the debug ip sla sender trace and debug ip sla sender error commands to help troubleshoot issues with an IP SLAs operation.

Procedure

Command or Action

Purpose

Step 1

enable

Example:

switch# enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

switch# configure terminal

Enters global configuration mode.

Step 3

feature sla sender

Example:

switch(config)# feature sla sender

Enables the IP SLAs operation feature.

Step 4

ip sla operation-number

Example:

switch(config)# ip sla 10

Begins configuration for an IP SLAs operation and enters IP SLA configuration mode.

Step 5

udp-jitter {destination-ip-address | destination-hostname} destination-port [source-ip {ip-address | hostname}] [sourceport port-number] [control { enable| disable}] [num-packets number-of-packets] [interval interpacket-interval]

Example:

switch(config-ip-sla)# udp-jitter 172.29.139.134 5000

Configures the IP SLAs operation as a UDP jitter operation and enters UDP jitter configuration submode.

Use the control disable keyword combination only if you disable the IP SLAs control protocol on both the source and target switches.

Step 6

frequency seconds

Example:

switch(config-ip-sla-jitter)# frequency 30

(Optional) Sets the rate at which a specified IP SLAs operation repeats.

Step 7

exit

Example:

switch(config-ip-sla-jitter)# exit

Exits UDP jitter configuration submode and returns to global configuration mode.

Step 8

ip sla schedule operation-number [life {forever| seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]

Example:

switch(config)# ip sla schedule 5 start-time now life forever

Configures the scheduling parameters for an individual IP SLAs operation.

Step 9

exit

Example:

switch(config)# exit

(Optional) Exits global configuration mode and returns to privileged EXEC mode.

Step 10

show ip sla configuration [operation-number]

Example:

switch# show ip sla configuration 10

(Optional) Displays configuration values including all defaults for all IP SLAs operations or a specified operation.

What to Do Next

To add proactive threshold conditions and reactive triggering for generating traps or for starting another operation, see the "Configuring Proactive Threshold Monitoring" section.

To view and interpret the results of an IP SLAs operation, use the show ip sla statistics command. Checking the output for fields that correspond to criteria in your service level agreement helps you to determine whether the service metrics are acceptable.

Configuring and Scheduling a UDP Jitter Operation with Additional Characteristics

This section describes how to configure and schedule a UDP jitter operation with additional characteristics.

- The IP SLAs UDP jitter operation does not support the IP SLAs History feature (statistics history buckets) because of the large data volume involved with UDP jitter operations, which means that the following commands are not supported for UDP jitter operations: history buckets-kept, history filter, historylives-kept, samples-of-history-kept, and show ip sla history.

- The MIB used by IP SLAs (CISCO-RTTMON-MIB) limits the hours-of-statistics kept for the UDP jitter operation to two hours. Configuring a larger value using the history hours-of-statisticshours global configuration change does not increase the value beyond two hours. However, the Data Collection MIB can be used to collect historical data for the operation. For information, see the CISCO-DATA-COLLECTION-MIB at http://www.cisco.com/go/mibs.

Tip

- If the IP SLAs operation is not running and generating statistics, add the verify-data command to the configuration of the operation (while configuring in IP SLA configuration mode) to enable data verification. When enabled, each operation response is checked for corruption. Use the verify-data command with caution during normal operations because it generates unnecessary overhead.

- Use the debug ip sla sender trace and debug ip sla sender error commands to help troubleshoot issues with an IP SLAs operation.

Before You Begin

Before configuring a UDP jitter operation on the source device, the IP SLAs Responder must be enabled on the target device (the operational target). The IP SLAs Responder is available only on Cisco NX-OS software based devices. To enable the responder, perform the task in the “Configuring the IP SLAs Responder on the Destination Device” section.

Procedure

Command or Action

Purpose

Step 1

enable

Example:

Switch> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Switch# configure terminal

Enters global configuration mode.

Step 3

feature sla sender

Example:

switch(config)# feature sla sender

Enables the IP SLAs operation feature.

Step 4

ip sla operation-number

Example:

Switch(config)# ip sla 10

Begins configuration for an IP SLAs operation and enters IP SLA configuration mode.

Step 5

udp-jitter {destination-ip-address | destination-hostname} destination-port [source-ip {ip-address | hostname}] [source-port port-number] [control {enable | disable}] [num-packetsnumber-of-packets] [interval interpacket-interval]

Example:

Switch(config-ip-sla)# udp-jitter 172.29.139.134 5000

Configures the IP SLAs operation as a UDP jitter operation and enters UDP jitter configuration submode.

- Use the control disable keyword combination only if you disable the IP SLAs control protocol on both the source and target switches.

Step 6

history distributions-of-statistics-kept size

Example:

Switch(config-ip-sla-jitter)# history distributions-of-statistics-kept 5

(Optional) Sets the number of statistics distributions kept per hop during an IP SLAs operation.

Step 7

history enhanced [interval seconds] [buckets number-of-buckets]

Example:

Switch(config-ip-sla-jitter)# history enhanced interval 900 buckets 100

(Optional) Enables enhanced history gathering for an IP SLAs operation.

Step 8

frequency seconds

Example:

Switch(config-ip-sla-jitter)# frequency 30

(Optional) Sets the rate at which a specified IP SLAs operation repeats.

Step 9

history hours-of-statistics-kept hours

Example:

Switch(config-ip-sla-jitter)# history hours-of-statistics-kept 4

(Optional) Sets the number of hours for which statistics are maintained for an IP SLAs operation.

Step 10

owner owner-id

Example:

Switch(config-ip-sla-jitter)# owner admin

(Optional) Configures the Simple Network Management Protocol (SNMP) owner of an IP SLAs operation.

Step 11

request-data-size bytes

Example:

Switch(config-ip-sla-jitter)# request-data-size 64

(Optional) Sets the protocol data size in the payload of an IP SLAs operation's request packet.

Step 12

history statistics-distribution-interval milliseconds

Example:

Switch(config-ip-sla-jitter)# history statistics-distribution-interval 10

(Optional) Sets the time interval for each statistics distribution kept for an IP SLAs operation.

Step 13

tag text

Example:

Switch(config-ip-sla-jitter)# tag TelnetPollServer1

(Optional) Creates a user-specified identifier for an IP SLAs operation.

Step 14

threshold milliseconds

Example:

Switch(config-ip-sla-jitter)# threshold 10000

(Optional) Sets the upper threshold value for calculating network monitoring statistics created by an IP SLAs operation.

Step 15

timeout milliseconds

Example:

Switch(config-ip-sla-jitter)# timeout 10000

(Optional) Sets the amount of time an IP SLAs operation waits for a response from its request packet.

Step 16

tos number

Example:

Switch(config-ip-sla-jitter)# tos 160

(Optional) In an IPv4 network only, defines the ToS byte in the IPv4 header of an IP SLAs operation.

Step 17

verify-data

Example:

Switch(config-ip-sla-jitter)# verify-data

(Optional) Causes an IP SLAs operation to check each reply packet for data corruption.

Step 18

vrf vrf-name

Example:

Switch(config-ip-sla-jitter)# vrf vpn-A

(Optional) Allows monitoring within Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs) using IP SLAs operations.

Step 19

exit

Example:

Switch(config-ip-sla-jitter)# exit

Exits UDP jitter configuration submode and returns to global configuration mode.

Step 20

ip sla schedule operation-number [life {forever| seconds}] [start-time {hh:mm[:ss] [monthday | daymonth] | pending | now | afterhh:mm:ss}] [ageoutseconds] [recurring]

Example:

Switch(config)# ip sla schedule 5 start-time now life forever

Configures the scheduling parameters for an individual IP SLAs operation.

Step 21

exit

Example:

Switch(config)# exit

(Optional) Exits global configuration mode and returns to privileged EXEC mode.

Step 22

show ip sla configuration [operation-number]

Example:

Switch# show ip sla configuration 10

(Optional) Displays configuration values including all defaults for all IP SLAs operations or a specified operation.

What to Do Next

To add proactive threshold conditions and reactive triggering for generating traps or for starting another operation, see the Proactive Configuring Proactive Threshold Monitoring .

To view and interpret the results of IP SLAs operations, use the show ip sla statistics command. Checking the output for fields that correspond to criteria in your service level agreement will help you determine whether the service metrics are acceptable.

Configuration Example for a UDP Jitter Operation

This example shows two operations that are configured as UDP jitter operations, with operation 2 starting five seconds after the first operation. Both operations will run indefinitely.

feature sla sender
ip sla 1
udp-jitter 20.0.10.3 65051 num-packets 20
request-data-size 160
tos 128
frequency 30
ip sla schedule 1 start-time after 00:05:00
ip sla 2
udp-jitter 20.0.10.3 65052 num-packets 20 interval 10
request-data-size 20
tos 64
frequency 30
ip sla schedule 2 start-time after 00:05:05

On the target (destination) device:

feature sla responder
ip sla responder

Chapter 2. Configuring IP SLAs UDP Jitter Operations for VoIP

This chapter describes how to configure an IP Service Level Agreements (SLAs) User Datagram Protocol (UDP) jitter operation to proactively monitor Voice over IP (VoIP) quality levels in your network, allowing you to guarantee VoIP quality levels to your users in IPv4 networks. The IP SLAs VoIP UDP jitter operation accurately simulates VoIP traffic using common codecs and calculates consistent voice quality scores, such as Mean Opinion Score (MOS) and Calculated Planning and Improvement Factor (ICPIF), between Cisco devices in the network.

Note

In this document, the term Voice refers to Internet telephony applications. The term Voice over IP can include the transmission of multimedia (both voice and video) over IP networks.

This chapter includes the following sections:

- Guidelines and Limitations for IP SLAs UDP Jitter Operations for VoIP

- Calculated Planning Impairment Factor

- Mean Opinion Scores

- Voice Performance Monitoring Using IP SLAs

- Codec Simulation Within IP SLAs

- IP SLAs ICPIF Value

- IP SLAs MOS Value

- Configuring and Scheduling an IP SLAs VoIP UDP Jitter Operation

- Configuration Examples for IP SLAs VoIP UDP Operation

- Configuration Examples for IP SLAs VoIP UDP Operation Statistics Output

Guidelines and Limitations for IP SLAs UDP Jitter Operations for VoIP

- This feature uses UDP traffic to generate approximate Voice over IP scores. It does not provide support for the Real-Time Transport Protocol (RTP).

- The Calculated Planning Impairment Factor (ICPIF) and MOS values provided by this feature, while consistent within IP SLAs, are estimates only and are intended only for relative comparisons. The values may not match values that are determined using other methods.

- Predictions of customer opinion (such as those listed for the E-Model transmission rating factor R and derived Mean Opinion Scores) that are determined by any method are intended only for transmission planning and analysis purposes and should not be interpreted as reflecting actual customer opinions.

Calculated Planning Impairment Factor

The ICPIF originated in the 1996 version of ITU-T recommendation G.113, “Transmission impairments,” as part of the formula Icpif = Itot - A. An ICPIF refers to the “calculated planning impairment factor.” The ICPIF attempts to quantify, for comparison and planning purposes, the key impairments to voice quality that are encountered in the network.

The ICPIF is the sum of measured impairment factors (total impairments or Itot ) minus a user-defined access Advantage Factor (A ) that is intended to represent the user’s expectations, based on how the call was placed (for example, a mobile call versus a land-line call). In its expanded form, the full formula is expressed as follows:

Icpif = Io + Iq + Idte + Idd + Ie - A

where

- Io represents impairments caused by nonoptimal loudness rating.

- Iq represents impairments caused by PCM quantizing distortion.

- Idte represents impairments caused by talker echo.

- Idd represents impairments caused by one-way transmission times (one-way delay).

- Ie represents impairments caused by equipment effects, such as the type of codec used for the call and packet loss.

- A represents an access Advantage Factor (also called the user Expectation Factor) that compensates for users who might accept some degradation in quality in return for ease of access.

ICPIF values are expressed in a typical range of 5 (very low impairment) to 55 (very high impairment). ICPIF values numerically less than 20 are generally considered “adequate.” While intended to be an objective measure of voice quality, the ICPIF value is also used to predict the subjective effect of combinations of impairments.

The following table, taken from G.113 (02/96), shows how sample ICPIF values are expected to correspond to subjective quality judgement.

Upper Limit for ICPIF

Speech Communication Quality

5

Very good

10

Good

20

Adequate

30

Limiting case

45

Exceptional limiting case

55

Customers likely to react strongly (complaints, change of network operator)

For more details on the ICPIF, see the 1996 version of the G.113 specification.

Note

The latest version of the ITU-T G.113 Recommendation (2001), no longer includes the ICPIF model. Instead, G.107 states “The Impairment Factor method, used by the E-model of ITU-T G.107, is now recommended. The earlier method that used Quantization Distortion Units is no longer recommended.” The full E-Model (also called the ITU-T Transmission Rating Model), expressed as R = Ro - Is - Id - Ie + A , provides the potential for more accurate measurements of call quality by refining the definitions of impairment factors (see the 2003 version of the G.107 for details). Though the ICPIF shares terms for impairments with the E-Model, the two models are different. The IP SLAs VoIP UDP Operation feature takes advantage of observed correspondences between the ICPIF, transmission rating factor R, and MOS values, but does not support the E-Model.

Mean Opinion Scores

The quality of transmitted speech is a subjective response of the listener. Each codec used for transmission of VoIP provides a certain level of quality. A common benchmark used to determine the quality of sound produced by specific codecs is the mean opinion score (MOS). With MOS, a wide range of listeners have judged the quality of voice samples sent using particular codecs, on a scale of 1 (poor quality) to 5 (excellent quality). The opinion scores are averaged to provide the mean for each sample.

The following table shows MOS ratings and the corresponding description of quality for each value.

MOS Ratings

Score

Quality

Description of Quality Impairment

5

Excellent

Imperceptible

4

Good

Just perceptible, but not annoying

3

Fair

Perceptible and slightly annoying

2

Poor

Annoying but not objectionable

1

Bad

Very annoying and objectionable

As the MOS ratings for codecs and other transmission impairments are known, an estimated MOS can be computed and displayed based on measured impairments. This estimated value is designated as MOS-CQE (Mean Opinion Score; Conversational Quality, Estimated) by the ITU in order to distinguish it from objective or subjective MOS values (see P.800.1 for details).

Voice Performance Monitoring Using IP SLAs

One of the key metrics in measuring voice and video quality over an IP network is jitter. Jitter indicates the variation in delay between arriving packets (inter-packet delay variance). Jitter affects voice quality by causing uneven gaps in the speech pattern of the person talking. Other key performance parameters for voice and video transmission over IP networks include latency (delay) and packet loss. IP SLAs allow you to simulate and measure these parameters in order to ensure your network is meeting or exceeding service-level agreements with your users.

IP SLAs provide a UDP jitter operation, which consists of UDP probe packets sent across the network from an origin device to a specific destination (called the operational target). This synthetic traffic is used to record the amount of jitter for the connection, as well as the round-trip time, per-direction packet loss, and one-way delay time (one-way latency). (Synthetic traffic indicates that the network traffic is simulated; that is, the traffic is generated by IP SLAs.) Data, in the form of collected statistics, can be displayed for multiple tests over a user-defined period of time, allowing you to see, for example, how the network performs at different times of the day or over the course of a week. The jitter probe can use the IP SLAs Responder to provide minimal latency at the receiving end.

The IP SLAs VoIP UDP jitter operation modifies the standard UDP jitter operation by adding the capability to return MOS and ICPIF scores in the data collected by the operation, in addition to the metrics already gathered by the UDP jitter operation. This VoIP-specific implementation allows you to determine the performance of your VoIP network.

Codec Simulation Within IP SLAs

The IP SLAs VoIP UDP jitter operation computes statistics by sending n UDP packets, each of size s, sent t milliseconds apart, from a given source switch to a given target switch, at a given frequency f. The target switch must be running the IP SLAs Responder in order to process the probe operations.

To generate MOS and ICPIF scores, you specify the codec type used for the connection when configuring the VoIP UDP jitter operation. Based on the type of codec that you configure for the operation, the number of packets (n), the size of each payload (s), the inter-packet time interval (t), and the operational frequency (f) are automatically configured with default values. However, you are given the option, if needed, to manually configure these parameters in the syntax of the udp-jitter command.

The following table shows the default parameters that are configured for the operation by codec.

Default VoIP UDP Jitter Operation Parameters by Codec

Codec

Default Request Size (Packet Payload) (s)

Default Interval Between Packets (t)

Default Number of Packets (n)

Frequency of Probe Operations (f)

G.711 mu-Law (g711ulaw)

160 + 12 RTP bytes

20 ms

1000

Once every 1 minute

G.711 A-Law (g711alaw)

160 + 12 RTP bytes

20 ms

1000

Once every 1 minute

G.729A (g729a)

20 + 12 RTP bytes

20 ms

1000

Once every 1 minute

For example, if you configure the VoIP UDP jitter operation to use the characteristics for the g711ulaw codec, by default a probe operation is sent once a minute (f). Each probe operation consists of 1000 packets (n), each packet containing 180 bytes of synthetic data (s), sent 20 milliseconds apart (t).

IP SLAs ICPIF Value

ICPIF value computation with the Cisco NX-OS software is based primarily on the two main factors that can impair voice quality: delayed packets and lost packets. Because packet delay and packet loss can be measured by IP SLAs, the ICPIF formula, Icpif=Io+Iq+Idte+Idd+Ie-A, is simplified by assuming that the values of Io, Iq, and Idte are zero, as follows:

Total Impairment Factor (Icpif) = Delay Impairment Factor (Idd) + Equipment Impairment Factor (Ie) — Expectation/Advantage Factor (A)

The ICPIF value is computed by adding a Delay Impairment Factor, which is based on a measurement of delayed packets, and an Equipment Impairment Factor, which is based on a measurement of lost packets. From this sum of the total impairments measured in the network, an impairment variable (the Expectation Factor) is subtracted to yield the ICPIF.

Cisco gateways use this formula to calculate the ICPIF for received VoIP data streams.

Delay Impairment Factor

The Delay Impairment Factor (Idd ) is a number based on two values. One value is fixed and is derived using the static values (as defined in the ITU standards) for Codec Delay, Look Ahead Delay, and Digital Signal Processing (DSP) Delay. The second value is a variable and is based on the measured one-way delay (round-trip time measurement divided by 2). The one-way delay value is mapped to a number using a mapping table that is based on a G.107 (2002 version) analytic expression.

The following table shows sample correspondences between the one-way delay measured by IP SLAs and Delay Impairment Factor values.

Sample Correspondence of One-Way Delay to ICPIF Delay Impairment

One-Way Delay (ms)

Delay Impairment Factor

50

1

100

2

150

4

200

7

Equipment Impairment Factor

The Equipment Impairment Factor (Ie) is a number based on the amount of measured packet loss. The amount of measured packet loss, expressed as a percentage of total number of packets sent, corresponds with an Equipment Impairment Factor that is defined by the codec.

The following table shows sample correspondences between the packet loss measured by IP SLAs and Equipment Impairment Factor values corresponding with each other.

Sample Correspondence of Measured Packet Loss to ICPIF Equipment Impairment

Packet Loss (as a percentage of total number of packets sent)

Equipment Impairment Value for PCM (G.711) Codecs

Equipment Impairment Value for the CS-ACELP (G.729A) Codec

2%

12

20

4%

22

30

6%

28

38

8%

32

42

Expectation Factor

The Expectation Factor, also called the Advantage Factor (A), represents the expectation that users might accept some degradation in quality in return for ease of access. For example, a mobile phone user in a hard-to-reach location might expect that the connection quality will not be as good as a traditional land-line connection. This variable is also called the Advantage Factor (short for Access Advantage Factor) because it attempts to balance an increased access advantage against a decline in voice quality.

The table below, adapted from ITU-T Rec. G.113, defines a set of provisional maximum values for A in terms of the service provided.

Advantage Factor Recommended Maximum Values

Communication Service

Advantage/Expectation Factor:

Maximum value of A

Conventional wire-line (land-line)

0

Mobility (cellular connections) within a building

5

Mobility within a geographical area or moving in a vehicle

10

Access to hard-to-reach location; (for example, via multi-hop satellite connections)

20

These values are only suggestions. To be meaningful, you should use the factor A and its selected value in a specific application consistently in any planning model that you adopt. However, the values in the table should be considered as the absolute upper limits for A.

The default Advantage Factor for IP SLAs VoIP UDP jitter operations is always zero.

IP SLAs MOS Value

IP SLAs use an observed correspondence between ICPIF and MOS values to estimate an MOS value.

Note

The abbreviation MOS represents MOSCQE (Mean Opinion Score; Conversational Quality, Estimated).

The E model, as defined in G.107 (03/2003), predicts the subjective quality that is experienced by an average listener by combining the impairment caused by transmission parameters (such as loss and delay) into a single rating, the transmission rating factor R (the R Factor). This rating, expressed in a scale of 0 (worst) to 100 (best), can be used to predict subjective user reactions, such as the MOS. Specifically, the MOS can be obtained from the R Factor with a converting formula. Conversely, a modified inverted form can be used to calculate R Factors from MOS values.

There is also a relationship between the ICPIF value and the R Factor. IP SLAs takes advantage of this correspondence by deriving the approximate MOS score from an estimated R Factor, which, in turn, is derived from the ICPIF score.

The following table shows the MOS values that are generated for corresponding ICPIF values.

Correspondence of ICPIF Values to MOS Values

ICPIF Range

MOS

Quality Category

0 - 3

5

Best

4 - 13

4

High

14 - 23

3

Medium

24 - 33

2

Low

34 - 43

1

Poor

IP SLAs always express the estimated MOS value as a number in the range of 1 to 5, with 5 being the best quality. A MOS value of 0 (zero) indicates that MOS data could not be generated for the operation.

Configuring and Scheduling an IP SLAs VoIP UDP Jitter Operation

Note

- Currently, IP SLAs supports only the following speech codecs (compression methods):

- G.711 A Law (g711alaw: 64 kbps PCM compression method)

- G.711 mu Law (g711ulaw: 64 kbps PCM compression method)

- G.729A (g729a: 8 kbps CS-ACELP compression method)

- The following commands, available in UDP jitter configuration mode, are not valid for UDP jitter (codec) operations:

- history distributions-of-statistics-kept

- history statistics-distribution-interval

- request-data-size

- Specifying the codec-type will configure the appropriate default values for the codec-interval, codec-size, and codec-numpacket options. You should not specify values for the interval, size, and number of packet options unless you have a specific reason to override the defaults (for example, approximating a different codec).

- The show ip sla configuration command will list the values for the number of statistic distribution buckets kept and statistic distribution interval (microseconds), but these values do not apply to jitter (codec) operations.

Tip

- If the IP SLAs operation is not running and generating statistics, add the verify-data command to the configuration of the operation (while configuring in IP SLA configuration mode) to enable data verification. When enabled, each operation response is checked for corruption. Use the verify-data command with caution during normal operations because it generates unnecessary overhead.

- Use the debug ip sla trace and debug ip sla error commands to help troubleshoot issues with an IP SLAs operation.

Procedure

Command or Action

Purpose

Step 1

enable

Example:

switch> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

switch# configure terminal

Enters global configuration mode.

Step 3

feature sla sender

Example:

switch(config)# feature sla sender

Enables the IP SLAs operation feature.

Step 4

ip sla operation-number

Example:

switch(config)# ip sla 10

Begins configuration for an IP SLAs operation and enters IP SLA configuration mode.

Step 5

udp-jitter {destination-ip-address | destination-hostname} destination-port codec codec-type [codec-numpackets number-of-packets] [codec-size number-of-bytes] [codec-interval milliseconds] [advantage-factor value] [source-ip {ip-address | hostname}] [source-port port-number] [control {enable | disable}]

Example:

switch(config-ip-sla)# udp-jitter 209.165.200.225 16384 codec g711alaw advantage-factor 10

Configures the operation as a jitter (codec) operation that will generate VoIP scores in addition to latency, jitter, and packet loss statistics.

Step 6

history enhanced [interval seconds] [buckets number-of-buckets]

Example:

switch(config-ip-sla-jitter)# history enhanced interval 900 buckets 100

(Optional) Enables enhanced history gathering for an IP SLAs operation.

Step 7

frequency seconds

Example:

switch(config-ip-sla-jitter)# frequency 30

(Optional) Sets the rate at which a specified IP SLAs operation repeats.

Step 8

history hours-of-statistics-kept hours

Example:

switch(config-ip-sla-jitter)# history hours-of-statistics-kept 4

(Optional) Sets the number of hours for which statistics are maintained for an IP SLAs operation.

Step 9

owner owner-id

Example:

switch(config-ip-sla-jitter)# owner admin

(Optional) Configures the Simple Network Management Protocol (SNMP) owner of an IP SLAs operation.

Step 10

tag text

Example:

switch(config-ip-sla-jitter)# tag TelnetPollServer1

(Optional) Creates a user-specified identifier for an IP SLAs operation.

Step 11

threshold microseconds

Example:

switch(config-ip-sla-jitter)# threshold 10000

(Optional) Sets the upper threshold value for calculating network monitoring statistics created by an IP SLAs operation.

Step 12

timeout microseconds

Example:

switch(config-ip-sla-jitter)# timeout 10000

(Optional) Sets the amount of time an IP SLAs operation waits for a response from its request packet.

Step 13

tos number

Example:

switch(config-ip-sla-jitter)# tos 160

(Optional) In an IPv4 network only, defines the ToS byte in the IPv4 header of an IP SLAs operation.

Step 14

verify-data

Example:

switch(config-ip-sla-jitter)# verify-data

(Optional) Causes an IP SLAs operation to check each reply packet for data corruption.

Step 15

vrf vrf-name

Example:

switch(config-ip-sla-jitter)# vrf vpn-A

(Optional) Allows monitoring within Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs) using IP SLAs operations.

Step 16

exit

Example:

switch(config-ip-sla-jitter)# exit

Exits UDP jitter configuration submode and returns to global configuration mode.

Step 17

ip sla schedule operation-number [life {forever| seconds}] [start-time {hh:mm[:ss] [monthday | daymonth] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]

Example:

switch(config)# ip sla schedule 5 start-time now life forever

Configures the scheduling parameters for an individual IP SLAs operation.

Step 18

exit

Example:

switch(config)# exit

(Optional) Exits global configuration mode and returns to privileged EXEC mode.

Step 19

show ip sla configuration [operation-number]

Example:

switch# show ip sla configuration 10

(Optional) Displays configuration values including all defaults for all IP SLAs operations or a specified operation.

What to Do Next

To add proactive threshold conditions and reactive triggering for generating traps or for starting another operation, see the Configuring Proactive Threshold Monitoring section.

To view and interpret the results of an IP SLAs operation use the show ip sla statistics command. Checking the output for fields that correspond to criteria in your service level agreement will help you determine whether the service metrics are acceptable.

Configuration Examples for IP SLAs VoIP UDP Operation

This example assumes that the IP SLAs Responder is enabled on the device at 101.101.101.1:

switch# conf terminal
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)# feature sla sender
switch(config)# ip sla 10
switch(config-ip-sla)# udp-jitter 101.101.101.1 16384 codec g711alaw advantage-factor 2
switch(config-ip-sla-jitter)# owner admin_bofh
switch(config-ip-sla-jitter)# precision microseconds
switch(config-ip-sla-jitter)# exit
switch(config)# ip sla schedule 10 start-time now
switch(config)# exit
switch# show ip sla config 10
IP SLAs Infrastructure Engine-III
Entry number: 10
Owner: admin_bofh
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: udp-jitter
Target address/Source address: 101.101.101.1/0.0.0.0
Target port/Source port: 16384/0
Type Of Service parameter: 0x0
Codec type: g711alaw
Codec Number Of Packets: 1000
Codec Packet Size: 172
Codec Interval (milliseconds): 20
Advantage Factor: 2
Verify data: No
Operation Stats Precision : microseconds
Operation Packet Priority : normal
NTP Sync Tolerance : 0 percent
Vrf Name: default
Control Packets: enabled
Schedule:
Operation frequency (seconds): 60  (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): 3600
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (microseconds): 20

switch#

switch# show running-config | begin "ip sla 10"
ip sla 10
udp-jitter 101.101.101.1 16384 codec g711alaw advantage-factor 2
precision microseconds
owner admin_bofh
ip sla schedule 10 start-time now
no logging console
.
.
.
switch# show ip sla configuration 10
Entry number: 10
Owner: admin_bofh
Tag:
Type of operation to perform: jitter
Target address: 101.101.101.1
Source address: 0.0.0.0
Target port: 16384
Source port: 0
Operation timeout (milliseconds): 5000
Codec Type: g711alaw
Codec Number Of Packets: 1000
Codec Packet Size: 172
Codec Interval (milliseconds): 20
Advantage Factor: 2
Type Of Service parameters: 0x0
Verify data: No
Vrf Name:
Control Packets: enabled
Operation frequency (seconds): 60
Next Scheduled Start Time: Start Time already passed
Life (seconds): 3600
Entry Ageout (seconds): never
Status of entry (SNMP RowStatus): Active
Connection loss reaction enabled: No
Timeout reaction enabled: No
Verify error enabled: No
Threshold reaction type: Never
Threshold (milliseconds): 5000
Threshold Falling (milliseconds): 3000
Threshold Count: 5
Threshold Count2: 5
Reaction Type: None
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (microseconds): 20
Enhanced History:

When a codec type is configured for a jitter operation, the standard jitter “Request size (ARR data portion),” “Number of packets,” and “Interval (microseconds)” parameters do not be appear in the show ip sla configuration command output. Instead, values for “Codec Packet Size,” “Codec Number of Packets,” and “Codec Interval (microseconds)” appear.

Configuration Examples for IP SLAs VoIP UDP Operation Statistics Output

This example shows how to display voice scores (ICPIF and MOS values) for the jitter (codec) operation:

switch# show ip sla st
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Type of operation: udp-jitter
Latest RTT: 11999 microseconds
Latest operation start time: 02:39:33 UTC Sat May 05 2012
Latest operation return code: OK
Latest operation NTP sync state: NO_SYNC
RTT Values:
Number Of RTT: 10
RTT Min/Avg/Max: 9000/11999/17000 microseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 microseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 microseconds
Jitter Time:
Number of SD Jitter Samples: 9
Number of DS Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 0/223/2001 microseconds
Destination to Source Jitter Min/Avg/Max: 0/2001/6001 microseconds
Packet Loss Values:
Loss Source to Destination: 0
Source to Destination Loss Periods Number: 0

Glossary

Term

Definition

codec

In the context of IP Telephony, a codec is a compression and decompression algorithm used to transfer voice and video data more efficiently. Voice codec types are typically referred to using the ITU recommendation number that defines the algorithm (for example, “G.711” instead of “PCM”).

CS-ACELP

The codec type defined in the reference documents G.729 and G.729A, Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP) .

ITU

The International Telecommunication Union. The ITU is an international organization within the United Nations System where governments and the private sector coordinate global telecom networks and services. The ITU Telecommunication Standardization Sector (ITU-T), responsible for defining standards (Recommendations) covering all fields of telecommunications, is one of the three operational sectors of the ITU. The ITU website address is http://www.itu.int.

ITU-T

ITU Telecommunication Standardization Sector. The ITU-T is one of the three operational sectors of the ITU and is responsible for defining standards (called ITU-T Recommendations) covering all fields of telecommunications.

MOS-CQE (Mean Opinion Score; Conversational Quality, Estimated)

The score calculated by a network planning model that aims at predicting the quality in a conversational application situation. Estimates of conversational quality carried out according to ITU-T Rec. G.107, when transformed to a mean opinion score (MOS), give results in terms of MOS-CQE.[1]

PCM

The codec type defined in the reference document G.711, Pulse code modulation (PCM) of voice frequencies .

[1] Definition from ITU-T Recommendation P.800.1. Used in accordance with the ITU Copyright and Disclaimer Notice.

Preface

This preface includes the following sections:

- Audience

- Document Conventions

- Related Documentation for Cisco Nexus 9000 Series Switches

- Documentation Feedback

- Obtaining Documentation and Submitting a Service Request

Audience

This publication is for network administrators who install, configure, and maintain Cisco Nexus switches.

Document Conventions

Command descriptions use the following conventions:

Convention

Description

bold

Bold text indicates the commands and keywords that you enter literally as shown.

Italic

Italic text indicates arguments for which the user supplies the values.

[x]

Square brackets enclose an optional element (keyword or argument).

[x | y]

Square brackets enclosing keywords or arguments separated by a vertical bar indicate an optional choice.

{x | y}

Braces enclosing keywords or arguments separated by a vertical bar indicate a required choice.

[x {y | z}]

Nested set of square brackets or braces indicate optional or required choices within optional or required elements. Braces and a vertical bar within square brackets indicate a required choice within an optional element.

variable

Indicates a variable for which you supply values, in context where italics cannot be used.

string

A nonquoted set of characters. Do not use quotation marks around the string or the string will include the quotation marks.

Examples use the following conventions:

Convention

Description

screen font

Terminal sessions and information the switch displays are in screen font.

boldface screen font

Information you must enter is in boldface screen font.

italic screen font

Arguments for which you supply values are in italic screen font.

< >

Nonprinting characters, such as passwords, are in angle brackets.

[ ]

Default responses to system prompts are in square brackets.

!, #

An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line.

Related Documentation for Cisco Nexus 9000 Series Switches

The entire Cisco Nexus 9000 Series switch documentation set is available at the following URL:

Click Here

Documentation Feedback

To provide technical feedback on this document, or to report an error or omission, please send your comments to nexus9k-docfeedback@cisco.com. We appreciate your feedback.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional information, see What's New in Cisco Product Documentation at: Click Here .

Subscribe to What's New in Cisco Product Documentation, which lists all new and revised Cisco technical documentation as an RSS feed and delivers content directly to your desktop using a reader application. The RSS feeds are a free service.

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

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.

This product includes cryptographic software written by Eric Young (eay@cryptsoft.com).

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. ( Click Here )

This product includes software written by Tim Hudson (tjh@cryptsoft.com).

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: Click Here . 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. (1110R)