Interconnecting MPLS clouds

Take a look at the shortcomings of MPLS across service provider networks to learn about interconnected MPLS clouds.

This Content Component encountered an error

This article will discuss more next generation capabilities of Multiprotocol Label Switching (MPLS) networks such as the ability to interconnect multiple provider backbones.

MPLS providers are constrained by the scope of their MPLS backbones. Similar to the early days of Frame and ATM when providers could only offer services out of the locations that were interconnected on their backbones, MPLS today faces the same restrictions. The advent of network to network interface connections (NNI) allowed carriers to interconnect their ATM and Frame backbones and to provide services that spanned multiple provider backbones. This advancement allowed carriers to offer Frame, Private Line and ATM virtual private networks (VPNs) globally. MPLS is following the same evolutionary process. Unless you are looking at services from a provider who has an international presence, it is not likely that the regional bell operators will be able to provide MPLS VPN services that span geographic regions outside the United States.

There are many issues associated with the interconnection of MPLS backbones not the least of which are service level agreements (SLAs). Think about it for a minute, MPLS enables the delivery of Quality of Service (QoS) across a provider's backbone. QoS is a much more difficult to manage than the normal availability SLAs associated with Frame and ATM circuits. Each provider has different SLAs associated with the various classes of service offered. Unlike ATM and Frame PVCs that are segmented into specific bandwidth increments, the providers can offer various classes of services each with different guaranteed bandwidth profiles. These vary from vendor to vendor and there are not preset standards for how QoS is implemented across the various classes of service. This is a major obstacle for interconnecting provider backbones, as it would be very difficult to provision a customer's service across multiple providers' backbones if they offer different service classes and SLA guarantees.

In addition to the provisioning issues there would be significant difficulty in determining who is at fault for SLA adherence issues. Imagine in the future that you wish to have a VPN spanning multiple provider backbones. You require certain SLAs for delay, packet loss and jitter as the VPN will be transporting Voice over IP (VoIP) traffic between your sites. Most people require end to end SLAs but in reality the SLAs will be measured point-of-presence (PoP) to PoP on the provider backbone. Let's say for this example that you have a remote site connected to Provider 1 and another connected to Provider 2. Provider 1 and Provider 2 have interconnected their MPLS clouds and are offering you these services with SLA guarantees. There are major obstacles to this. For example, do provider 1 and provider 2 even have the same guarantees? If so can they offer them to customers that are outside of their control? What happens when there is an issue with an SLA? Who does the customer contact? How is the issue of SLA adherence remediated between the carriers? Who pays the customer for non-adherence? Again these are major hurdles to interconnecting MPLS clouds. You may hear carriers discussing NNI connections between their MPLS backbones, but in the short term the services offered will not be nearly as robust as what is offered today.

As you can see, MPLS has a ways to go before it can provide the geographic footprint that Frame, ATM and Private Line VPNs offer today. This is not a technical issue as there are solutions for integrating MPLS backbones today. Most of the issues revolve around service delivery in terms of QoS and the Class of Service (CoS) offerings. In the next article, I will discuss the MPLS technologies for interconnecting the providers' clouds.

About the author: Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for SBC Communications. He has over 10 years of experience providing strategic, business, and technical consulting services to clients. Robbie resides in Atlanta, and is a graduate of Clemson University. His background includes positions as a Principal Architect at International Network Services, Lucent, Frontway and Callisma.

This article originally appeared on SearchNetworking.com.


 

This was first published in June 2006

Dig deeper on VoIP Migration and Implementation

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchMobileComputing

SearchNetworking

SearchTelecom

SearchITChannel

SearchEnterpriseWAN

SearchExchange

Close