The last article I wrote gave an overview of the bits used in the MPLS label to provide QoS over the MPLS backbone. In this article, before I get to configurations for MPLS EXP bits, I want to discuss MPLS QoS models.
QoS on an MPLS backbone is used to provide predictable, guaranteed performance metrics required to transport real time and mission critical traffic. The providers have an overall QoS architecture that is used to deliver a subset of QoS services to each customer. The provider will have multiple classes of service that the customers must align with in order to leverage the providers MPLS offering. The providers must have an MPLS QoS architecture that provides end to end guarantees for each class of service for each customer. Cisco, for instance, has defined two models that can be used independently or together to provide the end to end guarantees for each customer. Cisco defines these as the point to cloud and point to point models.
The point to cloud model or "hose" model allows the provider to provision an ingress committed rate (ICR) and egress committed rate (ECR) for each VPN. The ICR and ECR dictate how much bandwidth is allowed to enter and exit the service provider backbone within a VPN. The best way to describe the scenario is with an example. Let's say we have a VPN with 4 sites. Each of these sites can communicate with any of the other sites forming an any-to-any mesh. The sites are labeled site 1-site 4. I will use site 1 as the basis for discussion. The ICR can be set to only allow site 1 to inject 50Mbps of traffic into the cloud. This traffic can be destined to any of the other 3 sites. The ECR can be set to only allow 30Mbps traffic to exit the cloud to site 1 from the other 3 sites. These parameters can be set for each class of service. The provider's backbone will provide bandwidth and delay guarantees for the traffic thresholds as configured for the ICR and ECR. This model allows the provider's QoS to be transparent to the customer. The customer can dictate the amount of traffic that is sent to each of the provider's classes of service. The customer does not have to match the provider's classifications and the customer markings are preserved.
The point to point or "pipe" model allows the provider to build virtual QoS pipes between the customer edge routers that are used to provide bandwidth and delay guarantees. This is analogous to legacy ATM and Frame Relay PVC meshings. However, the provider is responsible for the virtual mesh. Once the virtual QoS tunnels are established the provider can offer traffic engineering across the virtual mesh. Each tunnel would have its own QoS characteristics so that the CE to CE QoS guarantees are established prior to transmission of data. This is a more granular approach to QoS and adds complexity to the provider's configuration.
In the previously mentioned hose model that provider has to compute the appropriate path for each customer and each class each time it transmits data. With the pipe model that path for each class is already established. The pipe model is not as scalable as the hose model as it requires CE to CE pipes for each customer.
Each of these models can provide QoS capabilities for the service provider. The driving factor is the services required by the end customer and the capabilities of the installed MPLS backbone.
I meant to cover the configurations for MPLS EXP bits in this tip, but I will save that for the next one.
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.
