Low Latency Queueing QoS on an MPLS Router with a Rate Limited Circuit

In a WAN architecture where routers have MPLS circuits with full bandwidth available, deploying LLQ on the WAN interface is simple as given in the example below. Here we classify the voice traffic with the ACL 140 and mark its precedence to 5 before leaving the serial interface. In addition, during times of congestion on Serial1/0, up to 1Mbps will be reserved for the voice traffic. The priority keyword ensures that this bandwidth is reserved and also ensures that the voice queue is processed before any other queue (up to 1Mbps). All other traffic will fall in a default class which follows the WFQ mechanism for QoS on the interface.

class-map match-all voice
  match access-group 110
policy-map privport-policy
  class voice
  set ip precedence 5
  priority 1000

interface Serial1/0
  ip address 10.22.13.1 255.255.255.252
  service-policy output privport-policy

access-list 110 remark Voice
access-list 110 permit ip host 10.10.1.15 host 10.20.1.15

This example is fairly straight forward and takes care of very simple applications that require voice and data transported over private WANs - whether these are private leased lines or MPLS circuits. Unfortunately, this method cannot be used when the circuit is rate limited. For example you have purchased a DS3 circuit (45Mbps) but are contracted to use just 6Mbps of that circuit. Common networking practice recommends policing the egress traffic at 6Mbps using CAR (Committed Access Rate), which rate limits the traffic to 6Mbps. Fair enough. The next logical step is to then apply LLQ policy (as depicted above) to the interface. Wrong! Recall that the rate limiting mechanism, although has some controls, is impartial as to what traffic it drops whenever the traffic exceeds the configured rate. This is a problem for any real time traffic, whether voice or video and the consequence is fairly obvious.

So how do we overcome this dilemma? The solution - use the Child Service Policy.

In our example we have a full DS3 that must be limited to 6Mbps. This implies that the total outbound traffic cannot exceed 6Mbps. In addition, prioritize voice for 1Mbps and in the absence of voice, data should be able to use available bandwidth up to 6mbps. The configuration below solves this problem.

class-map match-all voicesignal
  match access-group 120
class-map match-all voice
  match ip rtp 16384 16383

policy-map child-policy
  class voice
  priority 1000
  set precedence 5
class voicesignal
  bandwidth 100

policy-map parent-policy
class class-default
shape average 6000000
service-policy child-policy

interface Serial1/0
  ip address 10.71.28.138 255.255.255.252
  dsu bandwidth 44210
  service-policy output parent-policy

access-list 120 permit tcp any any eq 2000
access-list 120 permit tcp any eq 2000 any
access-list 120 permit udp any any eq 2000
access-list 120 permit udp any eq 2000 any

we first classified the voice packets into two parts - voice packets (uses rtp protocol) and the voice signaling packets (SCCP - Skinny Call Control Protocol). Yeah, you guessed it, we are using Cisco Call Manager! These packets are then mapped into a policy called 'child-policy' which gives priority to voice and reserves up to 1Mbps for it during times of congistion. At the same time, 100Kbps of bandwidth is reserved for the signaling packets so that other traffic cannot 'bump' these packets when congestion occurs.

The 'parent-policy' is shaped at 6Mbps and calls on the child-policy in a nested fashion. Think of the parent-policy as an interface running at 6Mbps and you are applying an LLQ policy to it just like in our first example above. The voice and data (default class) gets nicely queued up based on the policy before it hits the actual interface where the 'parent-policy' is applied.