QoS/VoIP Question

Unanswered Question
Sep 8th, 2010

Hi,

I'm hoping for some assistance on Policing Voice RTP/Signalling traffic on an edge router connecting into an MPLS cloud.

We are connecting VoIP (equipment does not support CAC) in addition to Data (Does not require prioritisation) and require the Voice Signalling (EF) to be prioritised over RTP (CS5).  The problem is that the MPLS cloud has a single queue which prioritises on DSCP 'EF' only.

In laymans terms what I am trying to achieve is as follows..There is 200k of bandwidth to play with at each site.  Ultimately the Signalling traffic has to take priority over Voice, which takes priority over other default traffic.  The signalling traffic is likely to operate at average 20k, but can burst up 165k during synchronisation.  The RTP is likely to average 40k, and burst up to 160k.

An example of what is configured on the Edge Router supplied by an unnamed service provider is as follows:

class-map match-any ef_output

match ip dscp cs5 ef

policy-map Outbound-to-MPLS

class ef_output

  police 200000 2000 2000 conform-action set-dscp-transmit ef exceed-action

set-dscp-transmit ef violate-action drop

I am intending to set this up in a lab environment but with my mediocre skills of QoS was hoping for some help.  If I seperate out the Class maps as in below, this will at least seperate out the CS5 and EF traffic at least at the Edge Router?(Like I say I'm assuming, don't have much experience with policing!)

class-map match-any cs5_output

match ip dscp cs5

policy-map Outbound-to-MPLS

class cs5_output

  police 40000 5000 15000 conform-action set-dscp-transmit ef exceed-action

set-dscp-transmit ef violate-action transfer

class-map match-any ef_output

match ip dscp ef

policy-map Outbound-to-MPLS

class ef_output

  police 20000 5000 19000 conform-action set-dscp-transmit ef exceed-action

set-dscp-transmit ef violate-action transfer

Perhaps I'm way off the mark with assuming the above would go someway to achieving the goal?  As mentioned ultimately what I'm trying to achieve is prioritise in order EF/CS5/Other traffic.  Additionally handle the burst of traffic, then we do burst we are not dropping packets (specifically the signalling which will cause system instability).

Any advice would be greatly appreciated.

Thanks,

Kevin

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Steven Holl Mon, 09/13/2010 - 07:04

Kevin,

First, I want to correct this:

 Ultimately the Signalling traffic has to take priority over Voice

Also, unless you're really rewriting your DSCP values on voice traffic, you're using the wrong values.  Voice signaling (control traffic) is DSCP AF31 or CS3 depending on where it is coming from.  RTP voice payload is DSCP EF.

You never want to put your signaling traffic in a priority queue.  The reason for this is that during a burst where the priority queue is exceeded, it can starve the signaling traffic completely, and cause issues like calls not being presented to the other side, or MGCP registration issues.  I often see issues where customer throw MGCP traffic in a priority queue, and due to the burst of traffic when the PRIs register (AUEP/response), the traffic is dropped at the edge and the endpoint never registers.  We actually make mention in the CUCM SRND to not put signaling traffic in a priority queue for this reason.

You are correct that you want to shape your interface to the speed of the link though, so that you move the congestion point to the router in which you can control QoS.

Here is a sample config which should work for you:

class-map match-any voice-control
  match ip dscp af31
  match ip dscp cs3
  match protocol mgcp
  match protocol h323
  match protocol sip
  match protocol skinny
class-map match-any voice-RTP
  match ip rtp  16384 16383
!
!
policy-map Voice-QoS
  class voice-RTP
   priority [bandwidth-value]
   set dscp ef
  class voice-control
   bandwidth [bandwidth-value]
   set dscp 0
  class class-default
   fair-queue

Note that I'm matching the priority queue based on RTP port range for Cisco products instead of DSCP EF.  I prefer this way due to a) some people have DSCP trustings misconfigured in the LAN and the DSCP/EF ends up getting stripped on a L3 switchport before it hits the QoS router and b) it prevents rogue traffic with DSCP/EF that isn't voice RTP from getting put in the priority queue.  This is also why I throw NBAR matching on for the signaling protocols.  It's a safety mechanism, since often times when I help people with QoS, I'm not looking at all of their DSCP trusting configuration upstream from the WAN edge.

Your RTP queue shouldn't be bursting to 400%.  RTP traffic is a consistent flow, and is really just based on codec and call quantity.  Priority queue size depends on the amount of calls which you want to sustain, and the codec/L2 overhead being used.  Calculate that here, and set the size for whatever the maximum you're willing to support before you run into call quality issues.  You can use CAC to control that only that amount of calls are allowed to be setup across the link, if desired:

http://tools.cisco.com/Support/VBC/do/CodecCalc1.do

The size of the priority queue should always match (or be less than) what the provider has provisioned for the priority queue.  That way, if there is congestion, you'll see it drop on your counters instead of it being dropped in the cloud where you don't have visibility.

For a rough estimate of the BW used for signaling traffic, use .25k per  IP phone/endpoint at the site.  Note that we're stripping the DSCP on  the signaling queue, since your provider doesn't have another queue  provisioned, and we *dont* want the potential for that traffic to get  dropped in the pri queue and starved.

After applying it, watch the output of 'sh policy-map int' to make sure you aren't taking drops on your priority queue or signaling queue.  If you see drops, the queue sizes either need to be raised for the amount of calls you push through the circuit, or you need to configure CAC to limit the amount of calls to what you have provisioned.

kgreenway Tue, 09/14/2010 - 01:02

Steven,

Thanks for taking the time to reply.

Interestingly the solution I got working was pretty much identical to yours, as I found exactly what you said in a lab environment (The priority queue completely starved the signalling).

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;}

class-map match-any Signalling
match  dscp cs6
match  dscp cs3

class-map match-any rtp

match  dscp cs5

!

!

policy-map Outgoing-QOS

class Signalling

  bandwidth 20

  set dscp cs3

class rtp

  set dscp ef

  priority 80

!

interface Serial0/0/0

bandwidth 200

ip address 172.170.11.1 255.255.255.0

clockrate 256000

service-policy output Outgoing-QOS

I understand what you are saying in respect to rogue traffic matching on these values, so will also take that into account.

Thanks again,

Kevin

Actions

This Discussion