is FRF.12 fragment size calculated based on CIR or on access rate?

[faimymolina]

Hello:

I have a question regarding LFI: is FRF.12 fragment size calculated using CIR or interface access rate (clock rate)?.

In the Ciscopress book "IP Telephony Self-Study Cisco QOS Exam Certification Guide, Second Edition",pag. 486 ( Link Efficiency Mechanisms chapter) the say: " One common misconception is that fragmentation size should be based on the CIR of the VC, rather than on the access rate. Fragmentation attacks the problem of serialization delay, and serialization delay is based on how long it takes to encode the bits onto the physical interface, which in turn is determined by the physical clock rate on the interface. So, you should always base FRF.12 fragmentation sizes on the clock rate (access rate) of the slower of the two access links, not on CIR."... which makes a lot of sense.

However, experts and other documentation I found online say that fragment size is based on PVC' CIR. Even in this forum I've found a lot of postings with people saying so.

Can any one clarify this, please?

Thanks a lot in advance.

Faimy

[Giuseppe Larosa]

Hello Faimy,

it is a good approach to compare different sources.

In the case of a standard it is often possible to access the original specification.

You can find FRF.12 spec at following link

www.broadband-forum.org/technical/download/FRF.12/frf12.pdf

First of all, the standard discriminates between locally defined fragmentation at DTE-DCE interface (=access link called UNI) or at an NNI interface between two DCE, and end to end fragmentation configured at DTEs.

End to End fragmentation is regarded as defined per PVC, local fragmentation is seen as defined per interface and affecting all PVCs defined on the access link.

paragraph 7 says:

"For End-to-End fragmentation, the maximum fragment size used on a particular PVC

depends on both the access line speeds at the two ends of the connection, the speeds of

any NNI interfaces on the path, and the delay and delay variation requirements of the

particular applications in use on the PVC. The maximum fragment size to send should be

configured on a per-PVC basis".

Clearly when we configure FRF.12 on routers we are using End-to-End fragmentation.

So the standard suggests that actually we have to look at access link speed when choicing the fragment size.

However, it makes a lot of sense to use the minimum between access link speeds and CIR as it represents the worst case.

Probably for this reason a lot of people look at the CIR.

To be noted in hub and spoke topologies even if VOIP installations are present only on few spoke sites, FRF.12 is effective from the hub/central site only if enabled on all PVCs.

Because a change in encapsulation occurs when using fragmentation both DTEs on a PVC have to be configured for FRF.12. So in hub and spoke scenario all routers have to be configured for FRF.12 even if only few sites host VOIP phones.

This is also not so immediate.

Clearly as true broadband access becomes more common and very cheap in some areas, the use of FRF.12 is becoming less common.

Hope to help

Giuseppe

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any  purpose. Information provided is for informational purposes only and  should not be construed as rendering professional advice of any kind.  Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever  (including, without limitation, damages for loss of use, data or  profit) arising  out of the use or inability to use the posting's  information even if Author has been advised of the possibility of such  damage.

Posting

Unless you're shaping to CIR, CIR does not impact end-to-end transmission bandwidth (it can impact end-to-end successful transmission though).  So, we should be able to discount CIR when not shaping.

Most WAN cloud technologies usually bottleneck at cloud ingress/egress.  So, the slowest (least bandwidth) link, usually an access link, would be the most critical as it would create the greatest serialization delay.

Serialization delay is cumulative, so just concerning ourselves with setting fragmentation for the slower access link's bandwidth can be insufficient to meet timing requirements.  (As also noted in Guiseppe's RFC reference.)  Further, frame-relay vendors are usually not going to re-order the (overall) packet stream on cloud egress, so egress fragmentation helps us not if they don't re-order.  (The primary purpose of this kind of fragmentation is to not overly delay an "important", e.g. VoIP, packet behind a large non-important packet being serialized.)

I agree fragmentation shouldn't be set simply to CIR, but conversely, "always" setting to slower (bandwidth) of the two access links is an over simplification.