This document discusses how MPLS can help address challenges with delivering VoIP over IP networks. MPLS allows traffic engineering to provide quality of service for real-time VoIP traffic. It enables differentiation of VoIP, data, and video traffic. MPLS is used by many service providers to guarantee bandwidth for VoIP through defined label switched paths. Non-intrusive testing of VoIP quality from a single network point allows detection of customer-impacting problems for efficient diagnosis and resolution.

1. Agilent
Testing VoIP on MPLS Networks
Application Note
Why does MPLS matter for VoIP?
Multi-protocol label switching (MPLS) enables a common IP-based network
to be used for all network services and for multiple customers of a network
operator. It allows IP networks to carry voice, data and video traffic with
differentiated service-level performance parameters. MPLS also enables
virtual private network (VPN) services over IP networks, so that a network
operator can offer private networking services to multiple customers on a
shared infrastructure. Although MPLS may be used with non-IP networks, it
is IP networking; and more specifically data, voice, video services over IP
networks; that makes MPLS an attractive and growing technology.
1

2. MPLS is used to ensure that all packets in a particular flow take the same
route over a backbone. Deployed by many telcos and service providers,
MPLS can enable traffic engineering to deliver the quality of service (QoS)
required to support real-time voice and video as well as service level
agreements (SLAs) that guarantee bandwidth. An MPLS network ingress
element attaches labels to IP packets. This label instructs the routers and
switches in the network where to forward the packets based on pre-
established IP routing information. Label switched paths (LSP) are defined
in routing tables, and are used to send tagged packets on specific paths
through the network. LSPs represent a new type of virtual paths for
segregating traffic in an IP network.
MPLS has been applied to implementing Virtual Private Networks, which is
a key revenue generator for service providers offering enterprise services.
MPLS has also been applied to enabling Class of Service (CoS) for multi-
service networks (voice, data, video) in conjunction with techniques
including DiffServ. For example, MPLS is used to distinguish and prioritize
VoIP traffic on a common IP network to ensure VoIP is delivered with higher
QoS objectives, and even to offer different levels of VoIP service quality.
MPLS can also be used to manage VoIP performance within a VPN.
The different QoS requirements of VoIP traffic, whether on a wholesale
basis when transported en masse on a common IP network or within VPNs,
can be met by using MPLS in conjunction with DiffServ, proper traffic
engineering, and other techniques.
Challenges with VoIP
Voice is a real-time service. It must be delivered with minimal delay (150
milliseconds end-to-end is a common recommendation) and it must be
reproduced with a constant bit stream on the egress network or endpoint.
Due to the delay requirements, IP retransmissions are not allowed.
Therefore, packets that are dropped on the network, or late packets dropped
by a jitter buffer, are not saved or reproduced.
IP’s best effort delivery and non-deterministic routing introduce delay and
more importantly variance in delay, also known as packet jitter, in the voice
transmission. VoIP packets may be lost due to packets dropped in router
queues or by the jitter buffer.
IP Performance Parameter End user and IP Network impacts
Packet Loss • Impacts voice clarity
Packet Delay • Impacts voice delay and echo delay
• Increases packet loss
Packet Jitter • Impacts voice clarity
• Increases packet loss
2

3. VoIP packet loss, delay and jitter are the key performance indicators of the
IP network performance. These IP network performance conditions interact
with VoIP processes (codecs, jitter buffers, packet loss concealment, echo
cancellers, silence suppression, etc.) in complex ways to impact voice
quality. The complex interactions of these processes and conditions can get
out of control and not only degrade voice quality, but do so in a way that is
difficult to diagnose and analyze. Figure 1 illustrates some of the cause-
effect relationships inherent among network conditions, network
performance parameters, VoIP processing parameters, and end user service
quality.
Figure 1: Any notion that end user voice quality can be determined by average loss and jitter measurements must be challenged
by this representation.
It is only in the context of a packet stream that these performance
indicators matter. Therefore, analysis for the purpose of troubleshooting
and diagnosing problems must focus on a problem domain. A problem
domain may be a segment of the network, traffic for a specific customer,
traffic from a specific endpoint, a virtual network, a call, or any combination
of these.
3

4. How to address these problems
By the time a network operator finally determines that service quality has
deteriorated, frustrated customers may have already “hung up” on both the
call and the service. To attract and retain customers, network operators
must have effective means for detecting service impairments and quickly
diagnosing the root cause so that the impairments can be fixed and the
service levels restored.
Considering the effectiveness and popularity of service-level management
and customer-centric management techniques, a top-downs approach to
problem resolution makes sense. This approach simplifies and expedites
problem resolution by allowing network technicians to use service-level
parameters to represent the impacts of network-level parameters, thus
abstracting a complex level of diagnostics and presenting information for
human consumption. This approach also makes more efficient use of
limited personnel. A problem is quantified and assessed based on its
potential impact to customers, thus focusing the valuable time of
technicians on resolving the problem that impacts customers and on
restoring service levels.
It is ultimately problems that impact end user service that must be detected.
Since several network performance parameters can affect end user service
in complex ways, it is useful to measure and present end user service
performance as a starting point.
Such testing can be performed using intrusive or non-intrusive methods.
Ultimately a combination of both provides the most robust and effective
means. For diagnoses and root-cause analysis of customer-impacting
problems in a live network, non-intrusive testing is the most common and
efficient means. Non-intrusive testing is simple and relatively inexpensive
because it does not require end-to-end equipment and control; it can be
done at a single point in the network. It also does not utilize network
bandwidth or traffic resources. It can offer visibility into network
performance (e.g., packet loss and jitter), and, based on new developments
enable speech quality to be accurately predicted based on non-intrusive
testing, end user service including voice quality score such as MOS and R
Factor. Finally, it can measure actual customer traffic. Therefore, it can be
used for many Operations Support Systems (OSS) and Business Support
Systems (BSS) applications.
A top-down approach, such at that illustrated in Figure 2, starts with
detecting a customer-impacting problem. This can be done with service-
level metrics such as MOS or R Factor measurements, which are provided
via non-intrusive testing on the Agilent Network Analyzer.
4

5. Figure 2: A tops-down approach to VoIP problem resolution
When a problem is detected, then a technician identifies what exactly is the
problem and where it is on the network. Typically in VoIP problems are due
to excessive RTP packet loss or jitter on the network. Identifying this
requires analysis of RTP packet loss and jitter for individual VoIP call
streams. However, prior to delving into the next layers, it is important to
know the nature of impairments such as loss and jitter. That is, are these
impairments bursty or random? Are they transient or persistent? Do they
occur in both streams/directions of a single call or only in one? Do they
occur at the beginning of calls or later? It is also valuable to locate where
on the network it may be occurring. By performing several single-point
measurements on different segments of the network (using a portable
Network Analyzer for example) one can quickly isolate these impairments.
A little bit of intuition, along with knowledge of the network topology and
results of the RTP analysis, can expedite this isolation process.
Finally, in order to fix the problem, one must diagnose the root cause. This
requires analysis of the underlying network layers. The Network Analyzer
provides integrated real-time layer 1-7 analysis of nearly all network
technologies and protocols in use today to expedite the VoIP problem
resolution process. Here follows an example:
Step 1:
A network technician views a list of VoIP calls on a network link and the
corresponding MOS for each call. The technician sorts calls on MOS from
lowest to highest, and then sees several calls with MOS falling below 3.0.
Step 2:
The technician views RTP performance statistics for bad calls, and sees if
excessive packet loss or jitter is directly correlated to drops in MOS. This is
shown in the Network Analyzer screen in Figure 3. In Figure 3a, MOS,
packet loss, packet jitter, and overall QoS are graphed normalized to their
pre-set red/yellow/green thresholds. One can see that when MOS breaks a
threshold into the red zone, it precedes a red zone entry of packet loss.
This is also indicated in Figure 3b, which shows MOS, packet loss, and
packet jitter graphed to their absolute values. Here, a drop in MOS score
(indicating a drop in voice quality) directly precedes a rise in packet loss.
One can correlate the voice quality impairment to packet loss. One also
sees a rise in packet jitter, but not a corresponding drop in MOS, indicating
5

6. that the packet jitter was not high enough to cause a noticeable impairment
in voice quality.
The Network Analyzer also shows the technician the nature of loss or jitter:
random or bursty, persistent or transient.
Figure 3a
Figure 3b
If poor MOS values are observed, but no packet loss on network, and
average jitter for each call is within acceptable limits (e.g., 50 msec), view
frame-by-frame jitter to see if a burst of late packets occur. This is shown in
6

7. Figure 4. Such a burst may not contribute significantly to an average jitter
measurement, but will nonetheless be dropped by the jitter buffer at the
destination. This will result in the same impact as packets dropped on the
network, and may contribute to voice quality problems.
Figure4 Bursts of high packet jitter
Step 3:
Drill-down to integrated layer 1-7 analysis to determine the root-cause of
the service quality problem, regardless of the infrastructure, technologies,
and protocols used to transport VoIP. The Network Analyzer provides
extensive measurement capability over all common layer 1 and 2
technologies and protocols.
• View layer 1-3 performance measurements to determine if high
utilization, low throughput, errored frames, or other network
condition has contributed.
• Run Expert Analyzer and Protocol Vitals to see key network health
and performance measurements at layers 2 and 3.
• See layer 2-7 protocol events and stats available in Commentators,
Connection Stats, and Protocol Stats.
• View physical layer events in Line Vitals
• Performance and events on Ethernet, ATM, multiport ATM IMA,
FR, PoS, HDLC, SDLC.
Underlying most VoIP problems is a network problem. If VoIP problems are
to be fixed and service levels restored, the capability to diagnose the
underlying network problem is absolutely required. The Network Analyzer
7

8. provides this top-to-bottom approach and complete layer 1-7 analysis
capability across all network topologies, technologies, and protocols.
After the root cause is diagnosed and fixed, one can verify the restoration of
service levels using end-to-end active testing methods such as those
provided by the Agilent Voice Quality Tester (VQT). The VQT can measure
end user voice quality from many different end user access points, including
analog POTS service, 10/100 Ethernet ports, IP phones, PBX and other
phones. The VQT is useful for certifying service levels on new VoIP
deployments and for verifying service levels after performing a problem
resolution operation as described above.
How MPLS-enabled analysis helps
The application of MPLS to IP networks adds a new challenge, but also a
new opportunity, for VoIP analysis and testing. The challenge is that VoIP
traffic from multiple different virtual networks and service class tiers are
mixed on common physical links. The opportunity is that MPLS provides a
means to separate this traffic for targeted analysis. It simply requires the
right tools to do this.
The Network Analyzer comprises many MPLS capabilities that not only
enable targeted VoIP analysis over MPLS in specific domains (VPNs, LSPs,
service tiers, etc), but also enable analysis of underlying network layers
including MPLS networks.
When MPLS is used in DiffServ architectures to provide prioritization for
different services, diagnosing performance problems can be significantly
expedited by focusing the analysis domain on specific LSPs. Using the
Network Analyzer, one can see VoIP performance for all traffic on a link,
and for traffic in specific domains. These domains can be based on MPLS
LSP, IP address, VLAN, ATM VP.VC, FR DLCI. To analyze in a specific
domain, one first applies a capture filter for a specific LSP. A filter can be
applied for up to 6 values of labels in a label stack. One can further filter on
specific values for Class of Service (CoS). This enables one to then analyze
VoIP for that LSP, for targeted analysis of performance for that service tier.
One can view traffic performance, for both VoIP and non-VoIP traffic, per
LSP and CoS.
For underlying network analysis, without LSP capture filters applied, one
can view traffic stats (utilization, DLL errors, throughput) per LSP for all
LSPs. This indicates if performance impairments are specific to LSPs. Such
conditions may be addressed by applying different prioritizations or routes.
One can also view frame size distribution per LSP to see if excessive
segmentation could contribute to network performance issues.
When MPLS is used to provide VPN services, diagnosing performance
problems can be significantly expedited by again focusing the analysis
domain on specific LSPs for specific VPNs. Using the Network Analyzer,
one can see VoIP performance for traffic on a specific LSP for a VPN. Other
8

9. domains for targeted traffic analysis include VLAN, ATM VP.VC, and FR
DLCI.
One first applies a capture filter for a specific LSP. Since label stacks are
sometimes used to differentiate traffic within a VPN, a filter can be applied
for up to 6 stacked values in a label stack. One can further filter on specific
values for Class of Service (CoS). This enables one to then analyze VoIP for
a specific VPN, and even for a specific tier of service or type of traffic (e.g.,
VoIP) for a VPN. One can view traffic performance, for both VoIP and non-
VoIP traffic, per LSP and CoS.
For underlying network analysis, without LSP capture filters applied, one
can view traffic stats (utilization, DLL errors, throughput) per LSP for all
LSPs. This indicates if performance impairments are specific to LSPs, and
may trigger the need to re-engineer routing or prioritization for a specific
VPN. One can also view frame size distribution per LSP to see if excessive
segmentation could contribute to network performance issues.
Problem solving guide using the DNA PRO or DNA MX
Plan
Establish VoIP service objectives, to determine measurement thresholds for
detecting and troubleshooting problems, and for verifying service
restoration.
• Primary service objectives refer to end user metrics such as those
for voice quality: clarity, delay, echo, etc. These will drive what the
secondary service objectives should be.
• Secondary service objectives refer to performance parameters that
are needed to deliver primary service objectives. These include IP
network performance parameters such as packet loss, jitter, and
delay.
Connect
Connect the DNA PRO or MX at the points of IP network access for VoIP
gateways and phones. The DNA may be connected to the network segment
via a Test Access Port (TAP) or data access switch, or may be connected
directly in-line or off a switch span port.
Configure
Setup capture filters for a specific MPLS LSP and/or CoS. (For MPLS
domain analysis. For other domains, filter on VLAN, VP.VC, DLCI, address,
or protocol).
To optimize real-time performance, setup a capture filter on protocol = RTP.
When troubleshooting root cause, disable this capture filter to view non-
VoIP traffic and events on the network.
To optimize real-time performance, configure the RTCP Monitor
measurement to generate MOS score and RTP stats for 20 RTP streams.
9

10. Monitor and detect
To run in real-time, begin the RTCP Monitor measurement in the Network
Analyzer.
Sort on the MOS column to place the calls with worst overall quality on top.
When MOS falls below threshold for one or more calls, stop the capture to
perform drill-down analysis on the traffic and events that contributed to the
drop in MOS.
Identify problem
View the graph of MOS, packet loss and jitter measurements (see Figure 3)
for the worst calls to determine the nature of problem: bursty loss, random
loss, excessive jitter (which contributes to loss at the jitter buffer). If
excessive jitter, note the round-trip delay measurement to see if that
parameter is contributing to jitter.
On the graph, right-click on spike in measurement, and select frame-by-
frame graph. Compare high frame-by-frame jitter values with jitter buffer
settings. If measured jitter is more than jitter buffer setting, VoIP packets
are probably being dropped. This has the same affect as packet loss. On
frame-by-frame graph, right-click on spike in measurement or missing
packet, and select to see decodes. This will show the RTP packet in context
with other frames received.
Analyze root cause
View layer 1-3 performance measurements to determine if high utilization,
low throughput, errored frames, or other network condition has contributed.
There are many measurements on the NA to help determine what is
happening on the network. Some examples:
• Run protocol vitals from capture buffer and observe pre-filter stats
to determine if any particular type of traffic is congesting the
network.
• Run Expert Analyzer, Protocol Stats, Connection Stats, Node Stats
from capture buffer, to determine if any events or data traffic are
impacting VoIP traffic.
• View layer 1 physical layer events in Line Vitals
• Disable capture filters and run a data capture to collect all traffic on
the network.
• View LSP Statistics measurement to see performance of all LSPs
on the network link.
• If VLAN, VP.VC, or DLCI are used, run these measurements to see
performance of all virtual channels
If packets are dropped on the network (determined by TNA packet loss
measurement) or at the jitter buffer (determined by TNA packet jitter
measurement), then that is a potential source of poor voice quality.
Determine if VoIP can be prioritized higher in queues, or rerouted during
peak traffic periods. Also try G.711 codec for less impact of dropped
packets, or try smaller frame sizes (10 msec instead of 20 or 30 msec).
10

11. Verify
After diagnosing the root cause and restoring the service, verify that service
levels are restored by measuring end-to-end service quality using the VQT.
Conclusion
MPLS enables service providers to deliver new services governed by
specific SLAs and COS. These services comprise the triple play: offering
real-time voice and video along with data on a common network. It is the
real-time services like voice that will generate the most revenue. The ability
to keep these services running at quality levels that meet customer
expectations is crucial to retaining customers and realizing revenues. While
MPLS introduces new challenges to diagnosing and troubleshooting
service-level problems, advanced tools like the Agilent Network Analyzer
makes this job simple and fast for next generation network engineers and
technicians.
Related Literature
Network Analyzer Data Sheet 5988-4176EN
Network Analyzer Technical Overview 5988-4231EN
DNA PRO Brochure 5989-3956EN
Telephony Network Analyzer Technical Overview 5988-7901EN
Voice Quality Tester Technical Overview 5968-7723EN
Figure 5 Distributed Network analyzer: Solutions for voice, data, video and mobile network test.
11

12. www.agilent.com
Online assistance: www.agilent.com/find/assist
By internet, phone or fax, get assistance with all your test and
measurement needs.
Australia 1800 629 485
Austria 0820 87 44 11
Belgium +32 (0) 2 404 9340
Brazil +55 11 4197 3600
Canada +1 877 894 4414
China 800 810 0189
Denmark +45 70 13 15 15
Finland +358 10 855 2100
France 0825 010 700
Germany 01805 24 6333
Hong Kong 800 938 693
India 1600 112 929
Ireland +353 (0)1 890 924 204
Israel +972 3 9288 504
Italy +39 (0)2 9260 8484
Japan 0120 421 345
Luxembourg +32 (0) 2 404 9340
Malaysia 1800 888 848
Mexico 01800 5064 800
Netherlands +31 (0) 20 547 2111
Russia +7 095 797 3963
Singapore 1800 375 8100
South Korea 080 769 0800
Spain +34 91 631 3300
Sweden 0200 88 22 55
Switzerland – French 0800 80 5353 opt. 2
Switzerland – German 0800 80 5353 opt. 1
Switzerland – Italian 0800 80 5353 opt. 3
Taiwan 0800 047 866
Thailand 1800 226 008
United Kingdom +44 (0) 7004 666666
USA 800 829 4444
Product specifications and descriptions in this
document are subject to change without notice.
© Agilent Technologies, Inc. 2000-2005
th
Printed in U.S.A. December 9 , 2005
5989-4492EN
5989-4492EN
12