DiffServ QoS over MPLS using EXP bits

[Venison Mogambi]

  We run a reasonably large WAN that has a mix of MPLS backbone links and conventional WAN circuits. We're deploying an enterprise QoS policy that identifies and marks traffic with DSCP values, so I've been trying to design a configuration that will preserve our DSCP values as traffic traverses our MPLS backbone links. I understand that there are configurations that will convert the DSCP values into EXP values, and I can then set policing or bandwidth guarantees for different traffic classes using the EXP values.

  But I'm confused about how to convert the EXP values back to DSCP values once the traffic arrives at the far end of an MPLS link. Are the DSCP values actually overwritten by the EXP values, or is the EXP value just a part of the MPLS label that gets "popped" off at the last MPLS router? If the EXP value gets popped off, should we be able to preserve the original DSCP value of the IP packet, and allow normal QoS queuing to take over once the packet is done traversing the MPLS core?

[Mohamed Sobair]

Hello,

There are different MPLS diffserv Tunneling techniques, each one relies whether on the Customer's markings OR the Service provider's marking , and accordingly you apply your QoS policy.

The Concept is very clear, once the Service Provider recieves Customer Markings (IPprecedence or DSCP), they whether remark it with specific EXP mpls bits value OR leave it to be copied to the Exp bits, the fact the ingress PE with the default behaviour Copies the the 1st 3bits of the TOS fields in the IP header into the EXP MPLS bits OR manually Set the EXP bits at the ingress PE.

If you have more than one label, the TOP label normally gets copies or rewritten in the MPLS core, keep in mind that those labels looses its EXP bits when it gets poped before the Egress PE, its therfore, REQUIRED to do extra configuration to make sure the MPLS EXP bits get Copied back into the IP Header because they are not copied back by default.

with these configuration , you ensure the markings are preserved across MPLS backbone when it gets forwarded from the egress PE to the CE router.

Regards,

Mohamed

[Venison Mogambi]

Hi,

Thanks for the feedback.

My issue with the EXP-to-DSCP copy is that the Cisco config I was using suggested using QoS groups. It seems to me this adds an extra unnecessary step to the process. I just want to match on EXP values and convert them back to DSCP values, not match on EXP values, convert them to QoS groups, then match those QoS groups to DSCP values.

One idea I had was to use NBAR to match on the traffic as it arrives over the MPLS link. We're planning to use NBAR on our PE routers to identify customer traffic and assign DSCP values, so why not use that same NBAR policy to match traffic as it arrives over the MPLS link? The last MPLS label would be popped off, leaving the original IP packet, and the NBAR policy would match against this packet and assign a DSCP value. Then the packet could get forwarded on and receive DSCP-based QoS treatment over any non-MPLS links.

It's just a theory, we'll see if that actually works...

[Mohamed Sobair]

Hi,

The QoS group is a Cisco router internal placeholder used here to temporarily store the MPLS EXP bit setting of packets that arrive at the PE router from P routers. This placeholder is necessary because the MPLS EXP bit settings are lost when MPLS labels are removed after the packets are received on the PE-P interface , remember that the output QoS treatment on the PE-CE interface must correspond to the MPLS EXP bit setting in a Pipe Model architecture, so it is essential not to lose these values.

Regards,

Mohamed