Regarding the QOS policy for Frame-relay

Unanswered Question
Dec 5th, 2007
User Badges:

I am having some doubts on the QOS policy implementation for frame relay solutions.


policy-map QPM_Q-FRsi-1024-512

class QPM_Q6

bandwidth percent 4

random-detect

class QPM_Q5

priority 153

class QPM_Q3

bandwidth percent 65

random-detect

class QPM_Q1

bandwidth percent 1

random-detect

class class-default

bandwidth percent 30

random-detect


interface Serial4/0.21 point-to-point

description abc

bandwidth 512

ip address x.x.x.x x.x.x.x

ip pim sparse-dense-mode

no ip mroute-cache

class QPM_Q-FRsi-1024-512



Normally for frame relay link we use to give bandwidth value equal to CIR of frame relay link.

So when I apply the policy to serial interface, QOS will check the bandwidth value and according to bandwidth value configured QOS will divide the bandwidth to different classes.

So I can,t go above the CIR value as QOS is dividing the bandwidth on CIR values.


so how I will use the port speed values which is more than CIR.


is it possible with QOS policy applied to go above CIR value?


Thanks

Mahi

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
Kevin Dorrell Wed, 12/05/2007 - 06:38
User Badges:
  • Green, 3000 points or more

Yes, you are right to have those doubts - well spotted!


In fact, what you have to do is define a map-class that tells how the frame-relay should behave on each individual DLCI. You attach your service policy to the map-class. You then have to tell the router that each DLCI belongs to that map-class. If you have different behaviors on different DLCIs, then just define several map-classes.


Kevin Dorrell

Luxembourg


mohindersingh Wed, 12/05/2007 - 07:10
User Badges:

Thanks for the reply...

Can you update me for ATM qos policies as we don,t have map classes for ATM links..

so if I am applying a QOS policy according to PCR, how I will be able to use SCR values...


policy-map Q-ATMsi-6000

class QPM_Q6

bandwidth percent 4

random-detect

class QPM_Q5

priority 1800 (30% of 6000)

class QPM_Q3

bandwidth percent 35

random-detect

class QPM_Q1

bandwidth percent 1

random-detect

class class-default

bandwidth percent 30

random-detect



interface ATM2/IMA0.xxx point-to-point

description to ustccr14 ATMx/x.xxx

bandwidth 6144

ip address xxxx.xxxx.xxxx.xxxx

ip pim sparse-dense-mode

pvc 1/40

vbr-nrt 7680 6144

no broadcast

oam-pvc 0

encapsulation aal5snap


As you can see from the policy i am applying the PCR values on the interface and for class5 also i have calculated value based on 6000. Class5 is served with LLQ mechanism..


So how my data traffic will reach the values of SCR...


Thanks

Mahi

mheusing Wed, 12/05/2007 - 07:01
User Badges:
  • Cisco Employee,

Hi Mahi,


The policy given implements queueing (and WRED, which does not change the arguments here). Queueing does only give minimum guarantees and does not specify an upper limit for the traffic.


So the policy given would not ensure, that you are within a given CIR value. Queueing only is used in case you overload the interface, which might be well above the CIR for a given PVC.


To impose an upper speed limit to the traffic you will need traffic shaping.


In addition your config does not apply the policy-map given, so I am assuming the config excerpt is not complete. You also use more than 100% of available bandwidth (sum of "bandwidth percent" + priority queue is above 100%), which seems odd.


A frame-relay QoS policy including traffic shaping would look like this:


policy-map MQC-FRTS-768

class class-default

shape average 729600 7296 0 ! Enables MQC-Based FRTS

service-policy FRqueueing ! Queues packets headed to the shaper

!

policy-map FRqueueing

class QPM_Q6

bandwidth remaining percent 4

random-detect

class QPM_Q5

priority 153

class QPM_Q3

bandwidth remaining percent 65

random-detect

class QPM_Q1

bandwidth remaining percent 1

random-detect

class class-default

fair-queue

random-detect

!

interface Serial4/0

no ip address

encapsulation frame-relay

!

interface Serial4/0.21 point-to-point

description abc

bandwidth 512

ip address x.x.x.x x.x.x.x

ip pim sparse-dense-mode

no ip mroute-cache

frame-relay interface-dlci 102

class FR-MAP-CLASS-768 ! Binds the map-class to the FR DLCI

!

map-class frame-relay FR-MAP-CLASS-768

service-policy output MQC-FRTS-768 ! Attaches nested MQC policies to map-class


The class "FR-MAP-CLASS-768" defines the PVC properties. The policy-map MQC-FRTS-768 and its shaper limit the traffic to CIR (assuming 768k in the example). You should leave some room for FR keepalives and L2 overhead, so shape to 729k and not to 768k.

The policy-map FRqueueing finally takes care of the queueing, I took your policy given and modified it to stay within the 100% available bandwidth.


For a detailed discussion of QoS on FR PVCs please also read the "Enterprise QoS Solution Reference Network Design Guide Version 3.3"

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a008049b062.pdf

and the section on "WAN Aggregator QoS Design", especially the Frame-Relay part of it.


Hope this helps! Please rate all posts.


Regards, Martin

mohindersingh Wed, 12/05/2007 - 07:21
User Badges:

Hi Martin,


Thanks for the reply...

I want to mention some points here...

First the bandwidth alllocated is fine in my query..it exactly calculates 100%.

But one thing still I want to ask like..when you give a bandwidth allocation to a class and apply the queuing, can that class use more bandwidth than configured?

if no, so how you said that the policy will not put a upper limit to the traffic?


Thanks in advance for replying..

mheusing Wed, 12/05/2007 - 07:35
User Badges:
  • Cisco Employee,

Hi,


The bandwidth allocation in your policy is 100% plus the priority queue (153 kbit/s) and that resultys in more than 100%, right?

In your config excerpt you do not apply the policy to anything, shich is done with a "service-policy output ..." command. Did you apply your policy?


Second, as I wrote, queueing does NOT implement an upper limit to traffic. In fact queueing with a smple - not nested - QoS policy is only used, if an interface is overloaded, which would be above port speed, i.e. usually ways above CIR.


If you configure "bandwidth percent 1" can this class send at interface speed? Clearly: YES.

"bandwidth X" gives a MINIMUM guarantee of X kbps, but NO upper limit other than interface speed.


If you want to limit FR traffic to CIR you have to use some sort of traffic shaping. One example for FR traffic shaping is given in my example policy above.



Regards, Martin


mohindersingh Wed, 12/05/2007 - 08:30
User Badges:

Hi Martin,


Thanks for replying...

As you said the port will be overloaded when the data flow reaches port speed and getting dropped on service provider end..

but if queuing starts when we cross port speed..

ok let us take a case that i am sending the data aboce cir but less than port speed..so the data above my CIR will be discard eligible..right?

so my data is getting dropped in cloud before queuing starts..

this is not the behaviour we look for frame relay QOS..

Normally we want the queuing starts before the data is set to DE bit 1.. i am not sure..but i think its like this..

so when my data crosses the CIR queuing should start so that data flow should not be more than CIR..

Correct me if I am wrong..

Like i am giving a strict priority to my voice data but my interface is not overloaded(less than prot speed) but my data is discard eligible above CIR, so my voice packets also could get dropped..which I don,t want..

Thanks for your time to give the replies..


Regards

Mahi

mheusing Wed, 12/05/2007 - 08:53
User Badges:
  • Cisco Employee,

Hi Mahi,


You are absolutely right about this. The consequence is to use a policy like the one in my example:

1) use traffic shaping to comply with CIR - otherwise the SP might drop your traffic

2) use a second policy to ensure VoIP gets preferential treatment within CIR, so no voip packets are droped by your router.

This way you can combine all requirements and get everything done properly.


Hope this helps! Please rate all posts.


Regards, Martin

mohindersingh Wed, 12/05/2007 - 09:18
User Badges:

Hi Martin,


Thanks for the reply.. but still my confusion persists..

As we say that QOS policy will not be in effect till the time congestion is not there..

As you said congestion occurs when i am transmitting data above port speed..

so when i am sending data below port speed..there is no qos policy in picture and my voip traffic is also not getting prefrential treatment..

it means my voip packet also get dropped..if i am sending data above CIR but less than port speed as my interface is not seeing any congestion..so what will happen in this case..

Or

If the qos policy will start when I send data above CIR, it seems lil logical..

below CIR no traffic drop and as i go above CIR, qos policy will be in picture and my voice packets will be getting prefential tratment and traffic going above CIR will belong to default class..

what do u say..


Mahi

mheusing Thu, 12/06/2007 - 01:42
User Badges:
  • Cisco Employee,

Hi Mahi,


The policy you initially gave will implement the first scenario you describe above, which is not desirable in your case. The example policy I gave will implement the second scenario you are describing in your previous post.


With a config as in my example actually there are two components: a shaper and queueing/WRED.

A shaper is always in effect. The shaper will make sure that your traffic stays within the specified CIR all the time. Queueing will only be used if required, i.e. if traffic arrives at a rate above CIR and thus can not be sent immediately.


What happens if traffic arrives above CIR but below port speed? The shaper will be active and release packets at a rate of CIR into the PVC, the rest of the packets arriving from the LAN is queued by the shaper.

This queueing could render your voice unusable, unless you specify another policy to describe which packets should be sent immediately by the shaper and which traffic can afford to wait (f.e. best effort, i.e. class-default).

So the combined policy, called nested QoS policies, will make sure you are not sending above CIR (shaper) and that your important traffic is sent first (queueing/WRED).

For voip this means lowest possible delay, but also DE=0 so that the provider will not drop it.

The example policy I gave will implement the second scenario you are describing in your previous post.


Hope this clarifies things a bit. Please rate all posts.


Regards, Martin

mohindersingh Thu, 12/06/2007 - 07:56
User Badges:

Thanks Martin,


You are a really nice core techy in Cisco technologies..

I salute your presence in forums man !!


OK now the last thing so that I can close the post..


Still you are saying for shaping the traffic arounf CIR..

So in this case if we do traffic shaping at CIR, it means when the data traffic throughput will go above CIR, traffic will be queued up and throuput on PVC will be same of CIR..

the thing is again we are roaming around CIR, how my data will reach to port speed values..

As i have paid to ISP for port speed more than cir VALUE..

so how i will utilize the free bandwidth given by my ISP..i mean bandwidth over CIR..


I hope i clear my point..


Regards

Mahi

mheusing Thu, 12/06/2007 - 13:09
User Badges:
  • Cisco Employee,

Hi Mahi,


Thank you for the compliment!

Could you have a look at "VoIP over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, LLQ / IP RTP Priority)"

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_configuration_example09186a0080094af9.shtml


A little search revealed: "Frame Relay Voice-Adaptive Traffic Shaping and Fragmentation"

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a00804554c5.html

This feature will throttle traffic to minCIR, if packets are in the voip class and otherwise send at CIR. In your case CIR would likely be set to port speed and minCIR to CIR.


Hope this helps!


Regards, Martin

Actions

This Discussion