Frame Relay LFI Using FRF12

Cisco IOS Software supports two flavors of Frame Relay LFI. The more popular option, FRF.12, is based on Frame Relay Forum Implementation Agreement 12, with the other option, FRF.11-C, being based on Frame Relay Forum Implementation Agreement 11, Annex C. FRF.12 applies to data VCs, and FRF.11-C applies to voice VCs. Because most Frame Relay VCs are data VCs, and because most service providers do not offer FRF.11 (VoFR) VCs, this section focuses on FRF.12. The final part of the FRF configuration section at the end of this chapter covers the differences between FRF. 12 and FRF. 11-C.

NOTE Another LFI feature, called multilink PPP over Frame Relay and ATM, also provides an option for LFI. This option is suited for environments that use Frame Relay/ATM internetworking and desire to run delay-sensitive applications such as VoIP on slow-speed WAN links.

FRF.12 varies greatly from MLP LFI in terms of how it works with queuing tools. IOS requires that Frame Relay traffic shaping (FRTS) be used to also use FRF.12. Remember all the trivia from Chapter 5, "Traffic Policing and Shaping"? You may recall that FRTS can apply queuing tools to shaping queues associated with each VC, but FRTS only allows a single FIFO queue on the physical interface. When you add FRF.12 to FRTS, however, two interface FIFO output queues are created rather than the single FIFO queue. Figure 7-9 shows the two FIFO interface output queues, called Dual FIFO queues, with FTRS and FRF.12.

Figure 7-9 Interface Dual FIFO Queues with FRTS and FRF.12 1500 Byte

Packet Arrives, Followed by One 60 Byte Packet

Packet Arrives, Followed by One 60 Byte Packet

Figure 7-9 focuses on the interface output queues, ignoring the shaping queues. Just like in the figure that depicted MLP LFI, a 1500-byte packet arrives, followed by a 60-byte packet. The large packet is fragmented into five 300-byte packets, with the first two being placed into the TX Queue, and the last three ending up in one of the interface output queues. The small packet arrives next, and it is not fragmented, because it is less than 300 bytes in length. It is placed into the other Dual FIFO queue.

Figure 7-9 focuses on the interface output queues, ignoring the shaping queues. Just like in the figure that depicted MLP LFI, a 1500-byte packet arrives, followed by a 60-byte packet. The large packet is fragmented into five 300-byte packets, with the first two being placed into the TX Queue, and the last three ending up in one of the interface output queues. The small packet arrives next, and it is not fragmented, because it is less than 300 bytes in length. It is placed into the other Dual FIFO queue.

This two-queue Dual FIFO structure acts like the queuing tools described in Chapter 4 in many ways. It has classification logic that places packets into one queue or the other (more on that in a few paragraphs). It has a number of queues (always two), and it has particular behavior inside each queue (FIFO). It also performs scheduling between the two queues using an algorithm such as Priority Queuing's (PQ) scheduling algorithm. Therefore, to understand what happens, you need to take a closer look at the classification logic and the scheduling algorithm applied to the Dual FIFO queues.

First, when a packet passes through the fragmentation step in Figure 7-9, if there are no packets in either Dual FIFO queue, and there is room in the TX Queue/TX Ring, the fragments get placed into the TX Ring/TX Queue until it is full. That's why in Figure 7-9 the first two fragments of the large packet got placed into the 2-entry TX Queue. Then, when the TX Queue is full, packets are placed into one of the two Dual FIFO queues.

IOS schedules packets from the Dual FIFO interface queues into the interface TX Queue in a PQ-like fashion. The logic treats one of the two Dual FIFO queues like the PQ High queue, and the other like the PQ Normal queue. The scheduler always takes packets from the High queue first if one is available; otherwise, the scheduler takes a packet from the Normal queue. Just like PQ, the scheduler always checks the High queue for a packet before checking the Normal queue. Although IOS does not give a lot of information about the two Dual FIFO queues in show commands, one command (show queueing interface) does list counters for the High and Normal queues. (This book refers to these two queues as the High and Normal Dual FIFO queues, even though most other IOS documents and courses do not even name the two queues.)

The classification logic with the FRF.12 Dual FIFO queues appears to be very straightforward. One popular school of thought concerns how FRF.12 classifies packets into the Dual FIFO queues, however, and another less-popular school of thought describes how classification really works. Most of the available references, including the courses on which the exams are based, state that the classification boils down to this:

• Fragmented packets are placed in the Normal Dual FIFO queue.

• Unfragmented packets are placed in the High Dual FIFO queue.

Putting the classification logic together with the queue service logic makes one neat package. LFI wants to interleave the small packets between fragments of the larger packets. By classifying the unfragmented packets into the High queue, and the fragments into the Normal queue, the PQ-like queue service algorithm interleaves unfragmented packets in front of fragmented packets.

In spite of what the courses actually say, FRF.12 actually classifies packets into one of the Dual FIFO interface output queues based on the queuing configuration for the shaping queues on each VC. FRTS allows a large variety of queuing tools to be configured for the shaping queues. Two of these queuing tools, if enabled on the shaping Queue of a VC, cause packets to be placed in the High Dual FIFO queue on the physical interface. Figure 7-10 outlines the main concept.

Figure 7-10 Classification Between FRTS LLQ Shaping Queues and Interface Dual FIFO Queues with FRF.12

Shaping Queues Created by LLQ Configuration

Figure 7-10 Classification Between FRTS LLQ Shaping Queues and Interface Dual FIFO Queues with FRF.12

Shaping Queues Created by LLQ Configuration

The figure depicts LLQ for the shaping queue on a single VC feeding into the interface Dual FIFO queues. The shaping logic remains unchanged, as does the LLQ logic for the shaping queues—in other words, with or without FRF.12 configured, the behavior of shaping acts the same. The only difference created by adding FRF.12 to FRTS comes when FRTS must decide which of the two interface Dual FIFO queues to place the packet into after the shaper allows it to pass. (Without FRF. 12, a single FIFO interface queue exists, in which case classification logic is not needed.)

As shown in the figure, the only way a packet makes it to the High Dual FIFO queue is to have first been in the low-latency queue. In other words, FRF. 12 determines which packets are interleaved based on which packets were placed into the low-latency queue in the shaping queue.

The classification logic and the scheduling logic make perfect sense if you consider the packets that need the minimal latency. When you purposefully configure LLQ for shaping queues, the class of packets you place into the low-latency queue must be the ones for which you want to minimize latency. FRF. 12 should interleave those same packets to further reduce latency; therefore, FRF.12 just places those same packets into the Dual FIFO High queue.

NOTE Because the Dual FIFO queues created by FRF. 12 essentially creates a high-priority queue appropriate for VoIP traffic, when you are using FRTS, Cisco also recommends configuring LFI on links that run at speeds greater than 768 kbps. However, you should configure the fragment size to something larger than the MTU—for instance, 1500 bytes. By doing so, no packets are actually fragmented, but VoIP packets can be placed in the high-priority queue in the Dual FIFO queuing system on the physical interface.

FRTS interaction and usage of queuing tools can be difficult to understand, let along trying to keep track of all the options. Interestingly, FRTS supports one set of queuing tools without FRF.12 enabled, and a subset with FRF.12 enabled, and with yet another subset of those (LLQ and IP RTP Priority) that actually interleave the packets. Table 7-9 summarizes the queuing tools and identifies when you can use them with FRTS and FRF.12.

Table 7-9 Queuing Tool Support with FRTS and FRF.12 (Cisco IOS Software Release 12.2 Mainline)

Desired Features

Queuing Tools Supported on Each VC (Shaping Queues)

FRTS only

FIFO, PQ, Custom Queuing (CQ), Weighted Fair Queuing (WFQ), Class-Based Weighted Fair Queuing (CBWFQ), LLQ, IP RTP Priority

FRTS with FRF.12 enabled

WFQ, CBWFQ, LLQ, IP RTP Priority

FRTS, FRF.12, with actual interleaving of packets

LLQ, IP RTP Priority

Choosing Fragment Sizes for Frame Relay

FRF.12 uses the same basic math as does MLP LFI to determine the fragment size—max-delay * bandwidth. But what do you use for bandwidth in the formula? CIR? Do you use the shaping or policing rate? Or the access rate, which is the clock rate used on the access link? Figure 7-11 shows a typical Frame Relay network that provides a backdrop from which to discuss which values to use.

Figure 7-11 Example Frame Relay Network Used to Explain How to Choose Fragment Sizes

CIR 64 kbps

Figure 7-11 Example Frame Relay Network Used to Explain How to Choose Fragment Sizes

CIR 64 kbps

In most cases, you should choose to fragment based on the slower access rate on either end of a VC, which in this case is the 128-kbps access rate on R1. The reason you should use the lower of the two access rates becomes apparent only when you think of serialization delay inside the cloud, and in both directions. First, consider left-to-right flow in the network. To reduce serialization delay to 10 ms on a 128-kbps link, the fragment size should be set to 160 bytes (128,000 * .01 = 1280 bits). When R2 sends a packet, the serialization delay takes 10 ms.

Moving from left to right, a full-sized fragment sent from FRS1 to the Main router takes only 0.8 seconds to serialize! Reversing the direction, a 160-byte fragment leaving router Main, going into the cloud, only takes 0.8-ms serialization delay, so you might be tempted to make the fragment size much larger for packets sent by router Main. When the packets get to FRS2, however, and need to cross the access link to R1, a small fragment size of 160 bytes gives you an advantage of low serialization delay. If you were to make the fragment size on the Main router a much larger size, the frame would experience a much larger serialization delay on the link from FRS1 to R1.

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.

FRF.12 configuration does not let you set the maximum delay, as does MLP LFI. Instead, you configure the fragment size directly. When planning, you normally pick a maximum serialization delay for each link first. So before you can configure FRF. 12, you need to calculate the fragmentation size. When you know the lower of the two access rates, and the maximum serialization delay desired, you can calculate the corresponding fragment size with the following formula:

Max-delay * bandwidth

Table 7-8, shown earlier in this section, lists some of the more common combinations of maximum delay and bandwidth, with the resulting fragment sizes.

Fragmentation with More Than One VC on a Single Access Link

Cisco IOS Software enables FRF. 12 per VC—in other words, you can perform LFI for the traffic on some VCs, but not others. Therefore, before configuring FRF.12, you should decide which VCs really need to use it.

You first need to determine whether any of the Frame Relay VCs need to use LFI. If the traffic on all the VCs can tolerate the delays without performing LFI, you are better off not fragmenting the frames. Fragmentation does increase the bandwidth required in the network slightly, because the fragmentation headers add a few bytes of overhead. Therefore, if serialization delay is not an issue, do not use FRF. 12 at all.

Most installations consider LFI when voice is added to the network. If voice is added to all sites in a Frame Relay network, of course you would consider LFI on all the VCs. The interesting choice comes when you have compelling reasons for LFI on some VCs, and not-so-obvious compelling reasons for others. The network in Figure 7-12 shows just such a network, with voice between the Main site and R1, and no voice to the other two remote sites.

Figure 7-12 Choosing Fragment Sizes

Figure 7-12 Choosing Fragment Sizes

In the figure, Main terminates three VCs that each share the same physical access link. Because voice traffic traverses the VC from Main to R1, LFI should be enabled on that VC, with the fragment size based on the slower of the two access links on either end of the VC. However, you should also enable LFI on all three VCs that terminate at Main.

The reason for LFI on all three VCs relates to an effect called egress blocking. Suppose that R1 sends a small voice packet, with R2 and R3 sending several large, unfragmented data packets. FRS2 receives the large packets first, and queues those packets to exit the access link to the Main router. The small voice packet arrives immediately after the large data packets, so the small voice packet must wait on the large packets to be forwarded.

Depending on the behavior of queuing in the Frame Relay switch, LFI may or may not help with the egress-blocking problem. With LFI on all the VCs, with the same general sequence of events, the small voice packet might just be behind a large number of small fragmented packets, rather than behind a small number of large packets. The Frame Relay switch might use a queuing algorithm that sends some frames from each VC intermittently, however, in which case LFI decreases the delay for the small voice packet. The key here is to understand how the VCs are configured to handle LFI.

For you exam takers out there, the general recommendation in the courses is to fragment on all VCs using a particular interface if at least one VC needs to use FRF. Therefore, in Figure 7-12, the only VC on which Cisco recommends not to bother with FRF.12 is the VC between R2 and R3.

MLP LFI and FRF both accomplish the same general task of reducing serialization delay for some packets. As seen in this chapter, the methods used by each differ in how each tool takes advantage of queuing tools. Table 7-10 summarizes the core functions of MLP LFI versus FRF.12, particularly how they each interact with the available queuing tools.

Table 7-10 Comparisons Between MLP LFI and FRF.12

Step in the Process

MLP LFI

FRF.12

Configures maximum delay, or actual fragment size

Maximum delay

Fragment size

Classification into the interface output queues

Based on the queuing tool enabled on the interface

All packets coming from LLQ or RTP Priority shaping queues placed in higher-priority queue

Number of interface output queues

Based on the queuing tool enabled on the interface

2 queues, called Dual FIFO

How queue service algorithm causes interleaving to occur

Based on queuing tool's inherent queue service algorithm; PQ, LLQ, and RTP Priority most aggressively interleave packets

PQ-like algorithm, always servicing High queue over Normal queue

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