As with most of the articles I have written, this one focuses on the user end of MPLS rather than the actual technical...
implementation of MPLS itself. However, it all ties into things you need to know when evaluating MPLS as a technology.
A true benefit of MPLS technology is the ability to provide Quality of Service (QoS) guarantees over an IP backbone. This allows service providers to carry real time traffic with service level agreements applied to the customer's mission critical applications and also supports VoIP and Video over IP. The fact that providers can now offer this allows customers to finally consider converged environments across a pure IP backbone. There are many areas that can be discussed when converging voice and data but the one I want to focus on is QoS and how the enterprise QoS architecture is impacted by the provider's QoS architecture.
When planning an internal QoS architecture that will utilize an MPLS VPN as the WAN backbone, it is beneficial to consider the provider's architecture. Service providers have enabled QoS with their MPLS VPN services. This allows the provider to offer multiple classes of service with SLA guarantees. The point I want to make is that the service provider's QoS architecture dictates how a customer's applications are serviced over their backbones. It doesn't matter what your QoS architecture is, it will have to be modified to match the provider's ability to deliver within their service parameters. The reality is that the provider has one QoS architecture and the customers can have many different ones. The provider is not going to adapt their architecture to the client's therefore it makes sense to understand what the providers offer before engaging in an internal QoS plan. I wrote an internal white paper recently where I did exactly this. I looked at what offerings the providers had and I incorporated this into Enterprise QoS architecture best practices.
The first thing you need to know is that most providers support only 3-4 classes of service. Some provide 5 classes of service but the majority fall into the first group. Secondly, the providers use DSCP for classification and marking. In most cases when you deploy a MPLS VPN WAN, you will need to classify and mark your QoS traffic before you hand it off to the provider. Some providers offer managed services and they will handle the edge router configurations, others provide templates. Either way, you as the customer are responsible for identifying the important traffic and either telling the provider how you want it classified or doing it yourself.
So knowing this, when you embark on a QoS architecture it really makes sense to keep the above in mind. Limit your number of classes of traffic to 3-4. You can put any applications you want into these three or four classes, the provider doesn't care. They will tell you what the performance guarantees are for each class, it is up to you to decide which applications require what guarantees. Use DSCP markings rather than IP Precedence at the WAN router edge. Most providers follow some form of assured forwarding markings for their classes and you can easily match the providers. If you don't know the providers markings beforehand, use the DSCP standards.
By performing these simple tasks, you will greatly enhance your internal QOS architecture's interoperability with the providers. You will not have to do a wholesale change in order to reap the benefits of QoS over MPLS WANs.
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.