FRF11C and FRF12 Comparison

Most of the coverage of LFI over Frame Relay has focused on FRF.12. However, IOS offers another Frame Relay LFI service called FRF.11-C. You can use each of these two LFI options only when you use particular types of Frame Relay VCs. To appreciate how the two options differ, you first need to understand these two types of VCs.

The Frame Relay Forum (FRF) created data VCs originally to carry multiprotocol data traffic, as defined in the FRF. 3 Implementation Agreements. Service providers around the world offer Frame Relay FRF. 3 data VCs.

Later, with the advent of packetized voice, the Frame Relay Forum decided to create a new type of VC that would allow for better treatment of voice traffic. The FRF created the FRF.11 Implementation Agreement, which defines Voice over Frame Relay (VoFR) VCs. These VCs still pass data traffic, but they also pass voice traffic. Therefore, if a Frame Relay switch knows that one frame is data, and another is voice, for example, the switch can implement some form of queuing to give the voice frame low latency. FRF.11 headers include a field that identifies the frame as voice or data, making it possible for the cloud to perform QoS for the voice traffic.

The key to understanding the difference between the two basic types of VCs is to look at the headers used when the frames cross the Frame Relay network. It helps to understand when VoFR VCs can be useful, and when they cannot. Figure 7-18 shows the framing when FRF.3 and FRF. 11 are used, both for IP telephony traffic and for local voice gateway traffic.

In all cases in the figure, G.729 codecs are used. With FRF.3 VCs, the IP Phone and voice gateway traffic sits inside IP/UDP/RTP headers. In other words, the IP Phones encapsulate the G.729 payload using VoIP, and the routers do the same for the analog and digital voice trunks. Although the packets traverse the Frame Relay network, all the voice traffic is considered to be VoIP traffic when you use FRF.3 data VCs.

Figure 7-18 Framing of Voice Traffic with FRF.3 and FRF. 11 VCs

With Data VC

IP Telephone Traffic

FRF.3 Header

IP

UDP

RTP

G.729 Voice

FRF.3 Trailer

Voice Gateway Traffic

FRF.3 Header

IP

UDP

RTP

G.729 Voice

With VoFR VC

IP Telephone Traffic

FRF.3

FRF.11

G.729

FRF.3

Header

Header

IP

UDP

RIP

Voice 1

Trailer |

Voice Gateway Traffic

FRF.3

FRF.11

G.729

FRF.3

Header

Header

Voice

Trailer

With FRF. 11 VCs, some voice traffic can be VoIP, and some can be VoFR traffic. The traffic to and from the directly attached analog and digital voice links can be encapsulated using VoFR, as shown in the lowest of the four example frames. The IP telephony traffic, however, still must be encapsulated first in IP, because the traffic must pass across other links besides this single Frame Relay cloud. The VoFR encapsulation requires far less overhead, because the IP, RTP, and UDP headers are not needed. However, VoFR you can use encapsulation only when the Frame Relay-attached routers are the endpoints for the packets holding the voice payload. Because the larger percentage of packetized voice over time will be from IP Phones and the like, VoFR services are not typically offered by Frame Relay providers.

FRF.11-C provides for LFI over VoFR VCs, similarly to how FRF. 12 provides LFI services for FRF.3 data VCs. Just like FRF.12, FRF.11-C uses Dual FIFO interface output queues, with PQ logic applied to the two queues. However, FRF. 11-C uses a different classification logic, as follows:

• VoFR frames are placed into the High queue on the interface.

• All data frames are placed into the Normal queue.

In the preceding figure, the VoFR frames created for the voice gateway would be placed in the High queue, but the IP Phone packets would be placed into the Normal queue, because they would be considered to be data.

The other main difference between FRF.11-C and FRF.12 has to do with how the tools decide what to fragment, and what not to fragment. FRF.12 fragments all packets over a certain length. FRF.11-C, however, never fragments VoFR frames, even if they are larger than the fragment size. FRF. 11-C fragments data frames only, and only if they are larger than the fragment size.

Table 7-15 summarizes some of the key comparison points about FRF. 12 and FRF. 11-C.

Table 7-15 FRF.11-C and FRF.12 Comparison

Table 7-15 summarizes some of the key comparison points about FRF. 12 and FRF. 11-C.

Table 7-15 FRF.11-C and FRF.12 Comparison

Function

FRF.12 Behavior

FRF.11-C Behavior

Queuing option on the interface output queues

Dual FIFO

Dual FIFO

Classification into the interface output queues

Based on queuing tool used for shaping, with LLQ and IP RTP Priority putting packets into the high-priority queue

Voice frames placed in High queue, all others in Normal queue, regardless of shaping queue configuration

Fragmentation based on size or type of packet

Based only on size; must be careful not to fragment voice packets

Non-VoFR (VoIP and data) frames fragmented if they exceed the fragmentation size; voice frames are not, regardless of size

Frame Relay network aware of voice vs. nonvoice frames, and acts accordingly

No

Yes

Underlying type of VC, and general public availability.

FRF.3, available from most if not all public Frame Relay services

FRF.11, not generally available from public Frame Relay services

Advance SEO Techniques

Advance SEO Techniques

Turbocharge Your Traffic And Profits On Auto-Pilot. Would you like to watch visitors flood into your websites by the 1,000s, without expensive advertising or promotions? The fact is, there ARE people with websites doing exactly that right now. How is that possible, you ask? The answer is Advanced SEO Techniques.

Get My Free Ebook


Post a comment