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 VoIP over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, IP RTP Priority).
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
For more information on document conventions, refer to the Cisco 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 voice traffic.
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 nonreal-time data.
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 frame-relay fragment fragment_size 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 Voice 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 Relay.
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 have configured.
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.
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.