Assigning traffic to MPLS service classes

In a recent newsletter, we referred to our analysis of the service-level agreements associated with some of the most commonly used MPLS services. We were surprised to find that in some instances, excess traffic would default to best effort if more traffic is put into the real-time traffic class than it is designed to handle.

We heard from a number of readers about this. Sean Walberg wrote: “Probably because that’s the behavior of priority queuing on Cisco routers, which is how real-time traffic would be implemented. Policing is what lets you remark traffic that is out of contract, and you don’t often see it on the priority queue.”

He added: “I think there’s a responsibility on the part of the customer to make sure they don’t overuse their real-time space, and not rely on the carriers. Voice traffic is rather predictable, unlike the other classes, so there are few valid excuses.”

We are not sure if Walberg is right about the behavior of priority queuing. However, there is no question that he is right about the fact that IT organizations have the responsibility to do careful engineering when they allocate traffic to an MPLS real-time traffic class.

In order to understand the complexity of assigning traffic to MPLS service classes it is helpful to realize that in most cases the cost of an MPLS circuit depends on the class of service profile. The class of service profile details what percentage of the MPLS circuit is allocated to each MPLS service class.

The bottom line: If IT organizations do not assign enough of the MPLS circuit to real-time traffic then one or more highly visible applications will likely perform badly. However, if the IT organization assigns too much of the MPLS circuit to real-time traffic the cost of the circuit increases significantly. The conclusion that we draw is that to get the most out of MPLS services, IT organizations need a better understanding of their applications than has been required to date.