This document discusses two of the Frame Relay Forum (FRF) standards
(FRF.11 and FRF.12) that fragment packets into smaller frames. For more
information on how to design and configure VoIP over a Frame Relay network,
refer to the document
over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, IP
There are no specific requirements for this document.
This document is not restricted to specific software and hardware
For more information on document conventions, refer to the
Technical Tips Conventions.
A big challenge with voice-data integration is to control the maximum
one-way end-to-end delay for time-sensitive traffic such as voice. For good
voice quality, this delay is less than 150 milliseconds (ms). An important part
of this delay is the serialization delay on the interface, which should not
exceed 20 ms. Serialization delay is the time it takes to actually place the
bits onto an interface.
Serialization Delay = frame size (bits) / link bandwidth (bits per second [bps])
For example, a 1500-byte (B) packet takes 187 ms to leave the router
over a 64 kbps link. If you send a nonreal-time data packet of 1500 B,
real-time (voice) data packets queue until the transmit of the large data
packet. This delay is unacceptable for voice traffic. If nonreal-time data
packets are fragmented into smaller frames, the frames are interleaved with
real-time (voice) frames. In this way, both voice and data frames can be
carried together on low-speed links without excessive delay to the real-time
FRF.12 is an implementation agreement that supports voice and other
real-time delay-sensitive data on low-speed links. The standard accommodates
variations in frame sizes in a manner that allows a mixture of real-time and
FRF.12 stipulates that, when fragmentation is on for a data-link
connection identifier (DLCI), there is fragmentation of only data frames that
exceed the specified fragmentation size. This arrangement allows small VoIP
packets, which are not fragmented due to the size, to be interleaved as frames
between large data packets that have been fragmented into smaller frames. This
improves the serialization delay for packets that leave the router. As a
result, voice packets do not wait for the process of large data packets.
In a VoIP implementation, Frame Relay (Layer 2 protocol) cannot
distinguish between VoIP and data frames. FRF.12 fragments all packets that are
larger than the fragment size setting. Configure the fragmentation
size on the DLCI such that voice frames are not fragmented. You can
configure the fragment size under the Cisco IOS® Software
map-class frame-relay command with the issue of the
command. The fragment size
is in bytes, and the default is 53 B. Many variables determine the size of the
voice packets. For more information on voice packet size, refer to the document
over IP - Per Call Bandwidth Consumption.
A Voice over Frame Relay (VoFR) implementation uses the FRF.11 to
define how voice and data are encapsulated on the Frame Relay DLCI. Thus, data,
fax signaling, and voice use FRF.11 encapsulation for transmission on a DLCI
that carries voice. To mix these traffic types on a DLCI, FRF.11 defines
subchannels (identifiable by channel IDs) within the DLCI. Each subchannel has
a header field that describes the frame payload type. FRF.11 can specify up to
255 subchannels per DLCI.
Note: If you have not configured DLCIs for VoFR, the DLCIs use standard
Frame Relay data encapsulation, as FRF.3.1 specifies.
FRF.11 Annex-C fragmentation describes the way an FRF.11 DLCI
(configured for VoFR) carries data. FRF.11 Annex-C includes a fragmentation
specification for the data subchannels.
Only frames with data payload type are fragmented. Frame Relay
distinguishes voice frames from nonreal-time data frames because the FRF.11
payload specifies the traffic type. Therefore, regardless of the voice frame
size, the voice frame bypasses the fragmentation engine.
There are several recognized forms of Frame Relay fragmentation:
FRF.11 Annex-C fragmentation—Used on DLCIs configured for VoFR.
FRF.12 fragmentation—Used on DLCIs that carry data (FRF.3.1) traffic,
which includes VoIP. The Layer 2 Frame Relay protocol considers the VoIP
packets to be data.
There is a common misconception that FRF.12 fragmentation supports VoFR
and a general unawareness that FRF.11 also specifies a fragmentation scheme.
This confusion results in misunderstanding about fragmentation for VoFR and
VoIP over Frame Relay. This list clarifies some key differences:
A Frame Relay DLCI runs either FRF.12 or FRF.11, but never both.
FRF.12 and FRF.11 are mutually exclusive.
If you have configured the DLCI for VoFR, the DLCI uses FRF.11. If
fragmentation is on for this DLCI, the DLCI uses FRF.11 Annex-C (or the Cisco
derivative) for the fragmentation headers.
If you have not configured the DLCI for VoFR, the DLCI uses FRF.3.1
data encapsulation. If fragmentation is on for this DLCI, the DLCI uses FRF.12
for the fragmentation headers. DLCIs which carry VoIP use FRF.12 fragmentation
because VoIP is a Layer 3 technology that is transparent to Layer 2 Frame
You can support VoIP and VoFR on different DLCIs on the same
interface, but not on the same DLCI.
FRF.12 fragments voice packets if you have set the fragmentation size
parameter to a value smaller than the voice packet size. FRF.11 Annex-C (VoFR)
does not fragment voice packets regardless of the fragmentation size that you
FRF.11 Annex-C only needs support in platforms that support VoFR.
Because the use of FRF.12 is predominantly for VoIP, it is important to support
FRF.12 as a general feature on Cisco IOS Software platforms that transport VoIP
over slow-speed WAN links (slower than 1.5 Mbps). For this reason, there is
support for FRF.12, in Cisco IOS Software Release 12.1.2T and later, on
nonvoice-gateway platforms such as the 805, 1600, 1700, 2500, 4500, and 4700.