• United States

Beware of gotchas in MPLS service-level agreements

Apr 20, 20062 mins

* Examining MPLS SLAs

In the last WAN newsletter, we discussed how far organizations are deploying MPLS-based services and what is motivating them to implement such services. Today, we’ll look at MPLS service levels.

We recently published an article on Webtorials about MPLS-based services. In preparing the article, we looked at the service-level agreements (SLA) of some of the major suppliers of MPLS-based services. Our research convinced us that any IT organization looking to deploy MPLS-based services needs to thoroughly review the relevant SLAs.

For example, one of the things we found was that a major MPLS service provider excluded from its SLA any outage of less than a minute in duration. We concluded that the provider must have a lot of brief outages. Regrettably, in most cases, even a brief outage is enough to cause a voice call to drop.

Most if not all MPLS service offerings have a service class that is intended for real-time traffic. We would like to believe that if more traffic is assigned to the real-time class than it was designed to handle, the excess traffic would default to the next most stringent traffic class. However, one of the SLAs we reviewed stated quite clearly that if more traffic is put into the real-time class than it is designed to handle, the excess traffic would be dropped. This would obviously cause visibly bad application performance.

As mentioned in the last newsletter, some of the IT professionals we spoke to said they were moving to MPLS to save money. In particular, if they implemented MPLS services with all of their traffic in a best-effort service class, they would save money over their current frame relay and ATM services.

For many reasons, it is difficult to say anything definitive about pricing. However, in a future newsletter we will look at MPLS service pricing and how that affects how IT organizations manage these services.

Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.

More from this author