FRTS traffic guarantees

jedellerby · ‎01-09-2007

Hi,

I need some help to understand if the following is possible and how it can be achieved:

I have a % of traffic which I need to guarantee will be passed over a Frame Relay PVC, call it stream 1. The % of traffic could be classified with an ACL if required and equates to a bandwidth of less than the CIR for the PVC. I also have other traffic which can be transmitted which may be more bursty and does not have the same requirement to be gauranteed transmission; it's okay if the network marks it DE or drops it, call it stream 2.

I suspect I can traffic shape the two traffic streams to ensure CIR is never exceeded. However, this will throttle the bursty traffic when it may not need to be.

Is there a way I can give the 2nd traffic stream the extra bandwidth it may need, albeit with the potential for discard. Yet, at the same time still be sure the first traffic stream is never dropped.

As I understand it, if I exceed the Bc + Be values, which I may do if I transmit stream 2 at greater than CIR, then I could jeopordise the stream 1 traffic as the PVC will now be overcommitted for the Tc period. Any stream 1 traffic may get dropped by the PVC, irrespective of any gaurantees the CPE router applies.

Have I understood the limitations of FRTS correctly, or is there a way to do this ?

Thanks

Jed

jedellerby · ‎01-11-2007

Nobody got any ideas on this, have I not explained the issue well ?

If I have a regular circuit with gauranteed bandwidth I can simply allocate a bandwidth to my priority traffic to ensure it gets through.

When it comes to frame relay I think things look different if I want to work with the uncommitted bandwidth that a PVC can offer. I want to be sure my priority data always falls within the committed bandwidth allocation, so effctively I need to throttle the PVC to CIR if the following condition exist:

- Combined non priority and priority data is greater than CIR (possibly minCIR in Cisco terms?)

At all other times the PVC can run up to PIR rate.

Now I describe it like this I think it's even less likely this can be done unless I always throttle to CIR.

Perhaps my best approach is to see if BECN is supported by the network and when I get BECN we throttle to CIR dropping the low priority traffic, and then let it move bvack up to PIR when the BECNs stop.

Any comments welcome,

Jed

mheusinger · ‎01-11-2007

Hi,

you could configure a shaper (or policer) for your priority traffic to not exceed CIR. In addition configure your other traffic to be transported with DE=1 and no upper limit.

Config could look like this:

ip cef

class-map match-all Important

match ip address 100 !describe the importatnt traffic ...

policy-map FR

class Important

shape average 64000 !replace with CIR

class class-default

set fr-de

interface Serial0

encapsulation frame-relay

frame-relay interface-dlci 100

class FRclass

map-class frame-relay FRclass

service-policy output FR

You need to adjust this to your environment.

Some documentation that might be useful:

"Policing and Shaping Overview"

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800bd8ed.html

"MQC-Based Frame Relay Traffic Shaping"

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

Hope this helps! Please use the rating system.

Regards, Martin

jedellerby · ‎01-11-2007

Martin,

Thanks for the input. I'm currently waiting to find out if the network supports CPE marked DE, if it does this I suspect this could be a useful part of the solution.

I think if I combine this with BECN, if that is supported then I will be able to minimise the chances of random traffic being dropped even more.

Thanks

Jed