Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
DQOS Exam Certification Guide - Cisco press.pdf
Скачиваний:
69
Добавлен:
24.05.2014
Размер:
12.7 Mб
Скачать

Link Fragmentation and Interleaving 525

show no packets have been in the low-latency queue. This example shows a perfect case where you have a VC (R3 to R2) that does not really need FRF for itself; FRF should be enabled, however, so that the small packets from other VCs can be interleaved.

The show queueing interface serial 0/0 command shows incrementing counters for both the High queue and the Normal queue. Because one voice call is using the VC from R3 to R1, the voice packets get placed into the R3-to-R1 VC’s low-latency queue, and then placed into the Dual FIFO High queue. (Interestingly, I did a few repetitive show queueing commands, once every 5 seconds, and saw the High queue counter increment about 250 packets per 5-second interval. With 20 ms of payload, each G.729 call sends 50 packets per second, so the counters reflected the fact that the voice packets from the low-latency queue were being placed into the Dual FIFO High queue.)

FRF.11-C and FRF.12 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.

526 Chapter 7: Link-Efficiency Tools

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

 

 

 

 

With Data VC

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IP Telephone Traffic

 

 

 

 

 

 

 

 

 

 

 

FRF.3

IP

UDP

RTP

G.729

FRF.3

 

 

 

 

 

 

 

 

 

 

 

Header

Voice

Trailer

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Voice Gateway Traffic

 

 

 

 

 

 

 

 

 

 

 

FRF.3

IP

UDP

RTP

G.729

FRF.3

 

 

 

 

 

 

 

IP

 

 

Header

Voice

Trailer

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SW1

R1

T/1 R2

SW2

IP

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

With VoFR VC

 

 

 

 

 

 

 

 

IP Telephone Traffic

 

FRF.3

FRF.11

IP

UDP

RTP

G.729

FRF.3

 

 

 

 

 

 

Header

Header

Voice

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.

Link Fragmentation and Interleaving 527

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

Function

FRF.12 Behavior

FRF.11-C Behavior

 

 

 

Queuing option on the interface

Dual FIFO

Dual FIFO

output queues

 

 

 

 

 

Classification into the interface

Based on queuing tool used for

Voice frames placed in High

output queues

shaping, with LLQ and IP RTP

queue, all others in Normal

 

Priority putting packets into the

queue, regardless of shaping

 

high-priority queue

queue configuration

 

 

 

Fragmentation based on size or

Based only on size; must be

Non-VoFR (VoIP and data)

type of packet

careful not to fragment voice

frames fragmented if they

 

packets

exceed the fragmentation size;

 

 

voice frames are not, regardless

 

 

of size

 

 

 

Frame Relay network aware of

No

Yes

voice vs. nonvoice frames, and

 

 

acts accordingly

 

 

 

 

 

Underlying type of VC, and

FRF.3, available from most if

FRF.11, not generally available

general public availability.

not all public Frame Relay

from public Frame Relay

 

services

services