Nmedia - Fotolia


What to look for when gauging MPLS performance

Quality of service and service-level agreements are just a few of the considerations enterprises must keep in mind when assessing global MPLS providers.

Editor's note: In the second part of this three-part series, Robert Sturt discusses the steps enterprises need...

to take when assessing a global multiprotocol label switching (MPLS) procurement strategy. Part one examined the importance of devising a strong business case before talking to prospective providers. This installment covers some of the specific capabilities an MPLS vendor should be able to provide. For additional help, see this companion step-by-step guide.

Quality of service

The term "quality of service" (QoS) is banded around as a cure-all feature to guarantee the performance of applications. We know QoS is able to have a profound impact on multiprotocol label switching (MPLS) performance when configured correctly because applications are prioritized as they travel across a MPLS network. That said, application bandwidth should be determined carefully and organizations must understand network performance in terms of latency and jitter. In other words, the value of QoS will be diminished if the underlying network performance is poor.

It's never a good idea for organizations to engineer their networks based on SLAs.

Service-level agreements (SLA), meanwhile, provide an indication of performance from the perspective of applications, repair times and delivery. It's never a good idea for organizations to engineer their networks based on SLAs, because service levels are merely a reflection of the performance of your procured network. Yet a global MPLS SLA will demonstrate the type of real-world expectations the provider will be anticipated to deliver throughout the contract.

Latency and jitter performance

The SLA for jitter and latency performance will generally cover the core network only and not the tail circuits, which connect your sites to the provider's network. The figures provided within SLA documents are often based on a monthly average, which provides a good indication of overall performance. In general, any latency and jitter  experienced will be lower than the indicated levels. What SLA documents will allow you to understand is whether or not the provider is able to support your delay-sensitive and mission-critical applications such as voice and video. With global MPLS networks, keep in mind that the tail circuits -- especially if they are geographically distant from the provider's network -- can affect performance.

Repair times

Repair times are just one part. The most critical element is how long it will take your provider to swap out hardware in the event of a malfunction. I recommend that any critical sites be designed with standby customer premises equipment to ensure that your business isn't affected if a component breaks down. The majority of providers will offer SLAs that dictate terms governing hardware replacement -- for example, a four-hour window. Above all else, understand the process of logging faults -- from start to finish. If your support request is urgent, it's critical that you have the ability to speak with an engineer who is in a position to make changes and troubleshoot as needed. If you are wasting time because you are instead speaking with a customer service agent whose primary responsibility is to log calls, then confusion and delay will most likely be the result.

Delivery and migration

When considering an SLA and providers in general, make sure you get information regarding how long it will take for your provider to deliver MPLS circuits and the steps you need to take when placing an order. Once you understand each delivery element, you'll have a better idea about the provider's SLA and how it's constructed and whether the promised service level is beneficial.

In part three of this series, we'll cover some of the key milestones for delivery and migration.

Next Steps

Designing a global infrastructure

Classes of MPLS service

VPN basics

This was last published in July 2014

Dig Deeper on WAN optimization and performance