A p p l i c a t i o n N o t e s 249A P P E N D I XAPPENDIX CAPPLICATION NOTESFrame RelayATM was originally intended for multimedia applications and, therefore, isdesigned for delay-sensitive, real-time implementation. On the other hand,Frame Relay was originally intended for interactive data applications, whichtend to be bursty and are delay tolerant since loss or errored frames can bedetected and resent. To maximize line utilization, Frame Relay uses variable-sized frames that expand or contract based on traffic volume. For voiceapplications, this can be a fatal problem; large frames on a slow link can beaddressed by constraining the frame size on voice DLCIs. The FRF.12Agreement was formulated to address this problem. Fragmentation queueingreduces both delay and delay variation by dividing large packets into smallerpackets for transmission and then reassembling them into original packets attheir destination.Setting the Fragment (Maximum Frame) SizeA good rule to follow when setting the fragment size is to set the size (in bytes)to the same value as the link rate (in kilobits). For example, if the link rate is512 kbps, set the fragment size to 512 bytes. This ensures frame transmission(serialization) delay stays at less than 8 ms and allows a deterministic valuewhen addressing network delay calculations. This rule works for any link rate asshown below.If “X” is the link rate in kilobits per second, then:Fragment size = X in bytesso thatTransmission delay = X bytes x 8 bits/byte/(X) x 1000 bits per second,which = 8/1000 s,which = 8 ms for any X.
