A while back I wrote an article on DSCP QoS over MPLS http://etherealmind.com/dscp-qos-over-mpls-thoughts/ , since that time I have been working on some service provider networks and thought this would be a good opportunity to expand what happens at the PE with regards to DSCP to Experimental bit mapping(Traffic Class).
I have put together a diagram to help illustrate how many different service providers customers traffic is aggregated at the service providers PE.
[caption id="attachment_183" align="aligncenter" width="300" caption="CEtoPEQoS"]
[/caption]
We can see in this example that each customer has different bandwidth requirements for voice and other traffic. We should also note that the PE is where we change from IP VRF domains to the MPLS domain of the Service Provider, once traffic is inside the MPLS we lose the ability to identify traffic on a per customer basis (in relation to QoS). When the traffic moves from the IP VRF domains to the MPLS domain labels are attached to the packets to be label switched over the Service Provider network and during this change we then set the Traffic Class (The EXP bit was renamed in rfc5462 to Traffic Class) on the MLPS packet to be used for QoS across the SP network. The configuration might look something like this:
There might also be some classes set aside for a scavenger class or network control class; I have omitted this in these examples to keep things simple.
These policy maps would be set on the ingress interface/port of the PE each customer connection.
The following policy map might be used on a PE to send traffic toward the service provider network.
We can see that traffic with different DSCP values coming in from different customers eventually get aggregated into MPLS Traffic Class values before they are sent through the service provider network. The service provider network uses the Traffic Class values to police or shape traffic depending on the policies defined inside the service provider network.
We should also note that as traffic moves from the IP VRF domains to the MPLS domain individual customer traffic becomes indistinguishable from each other(at at QoS Level) until they pop out at the other end of the service provider network back into their own VRF domains, therefore any per customer configuration inside the service provider network is very difficult. (This is my experience with Cisco Equipment and that when applying QoS inside the MPLS domain we are restricted to matching on EXP bit and possible Vlan ID if we were using VPLS.)
I thought I would follow on from my previous article and include some sample configurations to help you understand what is going on inside the service provider network, which should in turn help you understand your end to end communication across the MPLS network and how QoS is treated. I have simplified the configuration somewhat as typically there would be some QoS set aside for management and network control, but you should be able to get a feel from the above examples.
CE to PE
I have put together a diagram to help illustrate how many different service providers customers traffic is aggregated at the service providers PE.
[caption id="attachment_183" align="aligncenter" width="300" caption="CEtoPEQoS"]

We can see in this example that each customer has different bandwidth requirements for voice and other traffic. We should also note that the PE is where we change from IP VRF domains to the MPLS domain of the Service Provider, once traffic is inside the MPLS we lose the ability to identify traffic on a per customer basis (in relation to QoS). When the traffic moves from the IP VRF domains to the MPLS domain labels are attached to the packets to be label switched over the Service Provider network and during this change we then set the Traffic Class (The EXP bit was renamed in rfc5462 to Traffic Class) on the MLPS packet to be used for QoS across the SP network. The configuration might look something like this:
Cut Down Example Class map used for SP on PE
class-map match-any Voice
match ip dscp EF
class-map match-any Video
match ip dscp AF41
match ip dscp AF42
match ip dscp AF43
class-map match-any Critical-Apps
match ip dscp AF31
match ip dscp AF32
match ip dscp AF33
class-map match-any Other-Apps
match ip dscp AF21
match ip dscp AF22
match ip dscp AF23
class-map match-any General
match ip dscp AF11
match ip dscp AF12
match ip dscp AF13
There might also be some classes set aside for a scavenger class or network control class; I have omitted this in these examples to keep things simple.
Customer1 Policy Inbound - Applied on the PE on the Port Customer 1 is connected to
policy-map Cust1-In
class Voice
police cir 524288
conform-action set-mpls-exp-imposition-transmit 5
exceed-action drop
class General
police cir 1572864
conform-action set-mpls-exp-imposition-transmit 1
exceed-action set-mpls-exp-imposition-transmit 0
Customer2 Policy Inbound - Applied on the PE on the Port Customer 2 is connected to
policy-map Cust2-In
class Voice
police cir 1048576
conform-action set-mpls-exp-imposition-transmit 5
exceed-action drop
class Video
police cir 2097152
conform-action set-mpls-exp-imposition-transmit 4
exceed-action set-mpls-exp-imposition-transmit 0
class General
police cir 7340032
conform-action set-mpls-exp-imposition-transmit 1
exceed-action set-mpls-exp-imposition-transmit 0
Customer 3 Policy Inbound - Applied on the PE on the Port Customer 3 is connected to
policy-map Cust3-In
class Voice
police cir 1048576
conform-action set-mpls-exp-imposition-transmit 5
exceed-action drop
class Video
police cir 2097152
conform-action set-mpls-exp-imposition-transmit 4
exceed-action set-mpls-exp-imposition-transmit 0
class Critical-Apps
police cir 1048576
conform-action set-mpls-exp-imposition-transmit 3
exceed-action set-mpls-exp-imposition-transmit 0
class Other-Apps
police cir 5242880
conform-action set-mpls-exp-imposition-transmit 2
exceed-action set-mpls-exp-imposition-transmit 0
class Gerenal
police cir 95420416
conform-action set-mpls-exp-imposition-transmit 1
exceed-action set-mpls-exp-imposition-transmit 0
These policy maps would be set on the ingress interface/port of the PE each customer connection.
The following policy map might be used on a PE to send traffic toward the service provider network.
Service Provider class map, matching on EXP bit set in the previous policy
class-map match-any SP-Voice
match mpls exp 5
class-map match-any SP-Video
match mpls exp 4
class-map match-any SP-Critcal
match mpls exp 3
class-map match-any SP-Critcal2
match mpls exp 2
class-map match-any SP-Standard
match mpls exp 1
Example cut down policy map toward SP Network from PE
policy-map OUT-TO-SP-NETWORK
class SP-Voice
priority percent 30
class SP-Video
bandwidth percent 20
class SP-Critical
bandwidth percent 15
class SP-Critical2
bandwidth percent 5
class SP-Standard
bandwidth percent 25
Key Take Aways
We can see that traffic with different DSCP values coming in from different customers eventually get aggregated into MPLS Traffic Class values before they are sent through the service provider network. The service provider network uses the Traffic Class values to police or shape traffic depending on the policies defined inside the service provider network.
We should also note that as traffic moves from the IP VRF domains to the MPLS domain individual customer traffic becomes indistinguishable from each other(at at QoS Level) until they pop out at the other end of the service provider network back into their own VRF domains, therefore any per customer configuration inside the service provider network is very difficult. (This is my experience with Cisco Equipment and that when applying QoS inside the MPLS domain we are restricted to matching on EXP bit and possible Vlan ID if we were using VPLS.)
Summary
I thought I would follow on from my previous article and include some sample configurations to help you understand what is going on inside the service provider network, which should in turn help you understand your end to end communication across the MPLS network and how QoS is treated. I have simplified the configuration somewhat as typically there would be some QoS set aside for management and network control, but you should be able to get a feel from the above examples.
Nice post, as was the first one!
ReplyDeleteYour service provider here appears to provide QoS across the core, but some service providers just rely on overprovisioning in the core and don't actually provide any end to end QoS.
Regards,
Tony
Thanks Tony
ReplyDelete